Re: libgnustep-base split proposal

[Richard Frith-Macdonald]

On 19 Feb 2006, at 05:27, Andrew Ruder wrote:

> Hello all,
>
> 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."  Right now there are two prevalent options to utilizing  
> Obj-C
> in your program: GNUstep and OS X.  Obviously the biggest problem with
> OS X is that it is not free.  GNUstep, however, brings along a whole
> lot of other problems: crazy GNUstep/ directory structure, daemons,
> config files, etc.. etc..  A typical developer not familiar with  
> GNUstep
> sees these things and runs the other direction.

Is there actually real evidence of the above?  If so I think we need to
spend some time on publicity/education to let people know that the
problems are almost entirely imaginary.  Perhaps an introduction
telling people how things can be used with no setup at all, and
removal of a few warnings about missing setup.

> We are throwing away a tremendous opportunity here, you have lots of
> developers who *could* be using a large chunk of GNUstep regardless if
> they are not interested in the full GNUstep environment.  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.  We can easily fill the role that  
> libFoundation
> and derivatives are made to fill.  Why is there any more than a single
> free Foundation implementation being developed right now?  In essence,
> I'd like to propose that the -base library be split to fill this role.

I'm not convince that splitting is necessary or desirable.  On the  
downside,
a splitup would be  likely to add overall complexity and make things
less maintainable, would require additional work to put in place,
and might put off users by confusing them by making it less clear what
features are available in the software.
IMO our focus should be on trying to make  things ever simpler to use
so that they 'just work' rather than trying to pull out subsets of
functionality for other uses.

> Now, since you're still reading :) what I've discovered over the  
> course
> of the last couple weeks is that *most* of GNUstep really is just an
> object library.  I started by separating out the following files:
>
> NSConnection.m
> NSDistantObject.m
> NSDistributedLock.m
> NSDistributedNotificationCenter.m
> NSMessagePort.m
> NSMessagePortNameServer.m
> NSPortCoder.m
> NSPort.m
> NSPortMessage.m
> NSPortNameServer.m
> NSSocketPort.m
> NSSocketPortNameServer.m
>
> The distributed objects make GNUstep more than just an objects library
> due to the additional overhead of the daemons.

For me, distributed objects are one of the 'killer' features of the base
library and the desire to use DO is perhaps the main reason I started
GNUstep development!
There do seem to be some people who just hate daemons, but even
if you hate daemons that's no reason to get rid of DO since you can
use it without them.
What does need a daemon is NSDistributedNotificationCenter and
NSSocketPortNameServer.  Logically if you want to avoid daemons
then those are the only bits of functionality you remove.  Alternatively
you could says'not running daemons just loses you distributed
notifications and inter-host service lookup).

> \  The only two files
> besides these that didn't fit in the "just a library" paradigm were:
>
> NSBundle.m

Hmm ... not sure why you lump NSBundle in here ... to my mind it's
library code and doesn't *use* external resources, rather it makes
external resources available.

> NSUserDefaults.m
> Some parts of NSPathUtilities.m
>
> Now, these were *especially* tricky to remove from -base since they  
> are
> used everywhere.  After spending some considerable time (and lots of
> late nights ;)) I managed to get them removed in a manner that should
> allow them to be re-added in a library on top of -base.
>
> For the rest of this email I will refer to the eventual object library
> made out of the remaining files (NSString, NSDictionary, etc..) as
> "level1" and the above more-GNUstep-environment-centric files as
> "level2"
>
> The first change to level1 was to inventory exactly what it was  
> looking
> up in defaults and from NSBundle to guage what exactly needed to be
> abstracted.  In the end, I decided the best implementation would be to
> abstract all the uses into a GSDefaults class.  The GSDefaults  
> class is
> quite simple:
>
> @interface GSDefaults : NSObject
> [...]
> /**
>  * Resource path for level 1 base
>  */
> - (NSString *)baseResourcePath;
> /**
>  * Resource path for additions base
>  */
> - (NSString *)additionsResourcePath;
> [...]
> @end
>
> Of course, there are additional methods to deal with the other  
> defaults
> used throughout -base.  After the split, the GSDefaults in level1  
> could
> simply return the results obtained from ./configure, in level2 a
> category would be created that could also obtain this information from
> NSUserDefaults.

NSUserDefaults is already capable of running
a. with a read only defaults file
b. with no defaults file.

So what is the point of removing it and replacing it with another class?
Surely it would be much simpler to add an option to tell it that it's
*supposed* to be run without an external database, so it won't
generate any warning messages.

> If anyone has any specific objections to any part of this proposal,
> please reply with specific reasons why and how you think it could be
> done better.

That's a little tricky, because you start off with the assumption that a
splitup is a good thing and go on from there, but haven't actually
established a case.  I think in part because there is no clear idea
of what is to be achieved.

The clearest idea I get from this is a desire to be able to build a  
library
which uses no external resources.  That sounds pretty clear, and
as long as we ignore localisation (something we really should be
devoting time/effore to in the base library) pretty achievable.

However ... either configure-time or run-time options makes more
sense to me than a splitup.

Taking things point by point ...

1. Distributed Objects.

I distributed objects requires no external resources/daemons,,
so we can just keep it.

Host-local DO uses no daemon even for its name service.

Inter-host DO, if we are not going to run a nameserver,
we should extend the API a little to may it easier/clearer how to
run a DO server on a particular tcp port and how to connect to a
particular tcp port without a nameserver.

So a configure time option could disable NSSocketPortNameServer
in the headers and stop gdomap being built/installed.
A runtime option could stop it being used.

2. NSDistributedNotificationCenter

At present, this does require a daemon, so an option could remove/ 
disable it.
However, it seems to me that, at least for host-local notifications  
(which are all
that MacOS-X supports) it should be possible to rewrite this to work  
reasonably
(ie perhaps not all features) without a daemon ... so maybe that is  
worth doing.

3. NSUserDefaults

As I already mentioned, this already copes with read-only database,  
so it would
be easy to continue using it without any external files.  Major  
restucturing to
avoid using it therefore seems very counterproductive.

4. NSPathUtilities

Already requires no external files and contains elements designed to  
allow
Linux FSH integration (though that's largely a matter for the gnustep- 
make
package).

5. NSBundle

I'm not sure what the perceived problem is here.

6. NSTimeZone/NSTimeZoneDetail

You don't mention this ... but it does,  and must, use external  
resources.
It might be possible to map local system specific timezone management  
into it though.


> And P.S., I really *do* have a *severely* hacked -base on my system
> right now that I can link against and run programs with no environment
> variables, config files, or GNUstep/* directory structure ;)

I have an unmodified copy of the base library with which I can do the  
same thing  :-)

Basically, the base library can be used to build programs without  
most resources
and the vast majority of what it does use are options to give you  
more control
and I think I've outlined how we could avoid warning messages about  
missing
resources etc.

However, it seems to me that the starting point for this was the idea  
that some
people would be frightened of GNUstep...

If this is true, we need to combat it.
Where there are real problems, we need to address them ... but I  
think we need
to carefully identify real problems and deal with them individually.
My main impression however is that any issue is primarily one of  
publicity.