Re: libgnustep-base split proposal

[Helge Hess]

On 19. Feb 2006, at 06:27 Uhr, Andrew Ruder wrote:
> Objective-C is an incredible programming language, but right now the
> most crippling factor for its widespread use is the lack of a  
> "standard
> library."

Where did you get that conclusion I never heard about that one  
before! :-)

> GNUstep, however, brings along a whole
> lot of other problems: crazy GNUstep/ directory structure, daemons,
> config files, etc.. etc..

I wouldn't call the GNUstep directory structure crazy at all, its  
actually a rather cool thing.

Whats problematic is that it isn't possible to go w/o it and run  
GNUstep binaries/libraries like a regular Unix tool. Thats one of the  
reasons why its currently not possible for OGo to switch to gstep-base.

> Instead they waste their time (no offense intended) on  
> libFoundation and other such OpenStep-like API implementations,  
> because GNUstep is not flexible
> enough for their needs.

I don't understand the brackets, obviously this is offending. But no  
need to discuss it :-)

> We can easily fill the role that libFoundation
> and derivatives are made to fill.

Quite honestly I can't follow you, libFoundation was not made to fill  
missing flexibility in gstep-base, it was started a looong time ago  
by Ovidiu and others as a "pure" Foundation API implementation.
When they did that gstep-base was still quite an ugly mix of  
libobjects and Foundation. I think this was fixed reasonably well in  
the last years so the initial reasoning for libFoundation is gone  
(though I have the impression that gstep-base still contains too much  
GS* stuff).

> Why is there any more than a single
> free Foundation implementation being developed right now?

AFAIK there are three worth mentioning:
a) gstep-base
b) libFoundation
c) mgstep?

So now a bit about the "why".

a) well, thats the GNUstep community which doesn't want to drop gstep- 
base for
   unknown reasons ;-)

b) libFoundation is not really "developed", its more or less in  
"maintenance"
   mode. It does what it does and it does it well. The OGo project  
is more or
   less the only user of libFoundation (though lF very likely has  
multitudes
   more deployments than gstep-base).
   As mentioned before we would rather like to move OGo to gstep- 
base. If its
   possible w/o loosing features/speed/on-bugs which are important  
to us.

c) if I remember right the motivation behind mgstep is providing full
   binary compatibility with Cocoa. I think few people care about  
that and
   the huge additional maintenance overhead. Though I might be wrong.

Finally I think that there is nothing particulary bad with having  
multiple Foundation implementations which have different goals.
In contrary, its a demonstration of how well the Foundation API  
actually works and actually _the_ feature of GNUstep - since exactly  
this is what you do for Cocoa.

> In essence, I'd like to propose that the -base library be split to  
> fill this role.

Can't see how splitting will help since the main issue is not bloat  
but different goals or history or missing functionality.


If you want to know all the issues I have with using gstep-base  
instead of libFoundation, I could try to write that up. A major  
problem is that we don't have the time to fix/implement those issues  
in gstep-base (or bugs in gstep-base which might come up when using  
it with OGo!).

> Any thoughts?

I think you very much misinterpret the reasons why there are multiple  
Foundation libraries and your motivation to do changes might be a bit  
"inappropriate" (no offense ;-)

IMHO one should rather come up with a list of the features missing in  
gstep-base (like FHS support) and implement them step-by-step.

We would definitely like to move to gstep-base if certain things do  
work.

Also note that you will need to have MUCH better API/ABI stability if  
you want to become the "standard" library. This is also something  
which is lacking in GNUstep (not a core feature for us though, we  
would probably maintain our own _stable_ branch).

Greets,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org