[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libgnustep-base split proposal

From: Richard Frith-Macdonald
Subject: Re: libgnustep-base split proposal
Date: Sun, 19 Feb 2006 07:35:47 +0000

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:


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:


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.

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

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;

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 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]