Re: libgnustep-base split proposal

[Richard Frith-Macdonald]

On 22 Feb 2006, at 20:32, Matt Rice wrote:

> --- Richard Frith-Macdonald <address@hidden>
> wrote:
>
> > On 19 Feb 2006, at 22:30, Riccardo wrote:
> >
> > > Hey all,
> > >
> > >
> > > On Sunday, February 19, 2006, at 06:27 AM, Andrew
> > Ruder wrote:
> >
> > Jeremy Cowgar said that he had problems because the
> > base library
> > creates/uses a user defaults database, and he didn't
> > want it doing
> > that... so I spent a little while making that
> > behavior optional ...
> > and you can pick up the new version from svn.
> >
> > Setting the config value
> > 'GNUSTEP_USER_DEFAULTS_DIR=:INTERNAL:' will
> > tell it not to use the external defaults database
> > while keeping all
> > the rest of the defaults functionality intact.
>
> why not just have it instead of having to setup a
> config entry just not have it create the defaults
> database until something is written to defaults then
> if his program doesn't use it, it won't ever be
> created?

Not a problem ... but I expect people want it to not even try  
accessing the directory ... which is the reason for the option to  
turn it off completely.

> on the whole split proposal though,
>
> theres also NSProcessInfo which requires /proc or a
> specificially built gnustep-base with the user_main
> hack, making it impossible to use base in an init
> system without hard coding the mounting of /proc....
> though this isn't really a generic issue, and Andy
> didn't mention NSProcessInfo being one of the level 2
> classes.

I agree that the suggested split of classes doesn't make sense, but  
NSProcessInfo is not really an issue ... the use of /proc etc  is  
purely a convenience for writing  MacOS-X (previously OPENSTEP)  
compatible code ... in the sense of having the same code build and  
run the same in both platforms.
In the context of a standalone library ... the programmer just has to  
call NSProcessInfo's initialisation method explicitly.

Apart from localisation, NSTimeZone is really the one class in the  
base library where the absence of external resources is a real  
annoyance.  It can use the native timezone info, but that is *much*  
slower and more memory hungry for anything dealing with timezone  
abbreviations.  That's because the GNUstep timezone info contains  
files with pre-processed information that the class can read in ...  
when using native zone information the class has to load and parse  
*all* the individual timezone files to determine the available  
abbreviations.  So having the  library without the resources will  
run ... but will not be nearly as fast the first time it attempts to  
do data/time things.  Of course, it won't be any slower than other  
implementations either, but it seems ironic that a standalone  
'lightweight' installation means a slower more memory hungry one.