Re: libgnustep-base split proposal ... alternative ideas

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

I hope I addressed points about gnustep-base without external
dependencies in another mail

> 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 don't think libFoundation is more flexible than GNUstep-base ...  
rather
it's different, and I don't really see why gnustep needs to try to  
'beat' it.
However, if that's what you want, it might be good to identify *exactly*
why some people prefer it.
I've heard its string handling is fast but non-unicode (haven't looked
for ages), perhaps it's the memory footprint and speed of strings?
Is there any way to do a survey of why people use alternative
implementations?  if you only ask one or two people you can get
very skewed answers and waste time on work that actually puts the
majority of people off!  Even where you do ask about things, often
a perceived problem is not the same as the real problem.  For instance
I'm pretty sure there is a fork of GNUstep which came about because
of a disagreement about coding style (indentation etc)!
Anyway, my point is, the more information the better, we should ask ...
do you know of any appropriate mailing lists for other implementations?

I'm not sure about flexibility ... I often think we may be too flexible.
I don't really mean that we should reduce that flexibility, but I do  
think
we need to look into how we can make it really, really simple to manage.

I think we could be providing various introductory HOWTOs to tell
people how to configure things to be used for particular tasks.
Ideally, we would have scripts to do the job for them, so what I  
envisage
is something on the lines of ...
A web page for a particular type of usage of the system ... with  
keywords
to try and make sure it's easily found.  It would start with an  
introduction
describing what sort of setup it's for (so people know they are in the
right place), then provide a link to a script to do the setup for  
them and
instructions on how to use it.
Finally it would provide a detailed explanation of how this setup  
actually
differs from the standard one... this would be the optional part  
intended
for people who want to know what they are doing and why.

Possible setups might be ...

Linux FHS installation (really just needs implementing in gnustep-make)
Windows standalone package
Resource-free library usage
Freely relocatable installation
Securely locked-down installation
Developer/debug installation
Multiple installations on one machine
etc
...

Now, while the documentation (and the scripts) are the really important
bits, there is also an issue of how things are actually implemented.
At present we have a mixture of configure-time options, run-time
options controlled by environment variables, run-time options controlled
by config files, and run-time options controlled by user defaults.
I'd like to emphasise that all of these are *options* (ie the system  
will
normally run just fine if you know nothing about them), but if you do
want to use them it's hard to keep track of them all even though they
are mostly documented fairly well.

I know you don't like external config files, but a lot of discussion  
went into
the design of the current config file system ... between weeks of  
discussion
on the mailing list and off-list and also some hours of phone  
conversation
on fine details.  I believe we now have a good solid design there which
we can build on for consolidating control of most of the optional stuff.

If you really must get rid of the config file, you should be able to
configure the base library so that all the options you might have
specified in the file are built-in to the library but ...

I don't believe we want to get into different builds of the library.
insterad we need a system where we produce only one build for
each platform (heck, we haven't even managed to do that yet)
available for download.
We should allow people to customise its behaviour once they
have downloaded it, and a single config file found in a standard
location is ideal for that.

I suppose you could also have an installer script capable of installing
just a subset of the system (eg the shared library and headers) from
the downloaded package ... but it might be better to install everything
so that people can change their config without having to re-install.

Now, the config file is not essential (because default values for its
contents are built into the base library at configure time) ... but I  
don't
think it's unreasonable to have the library use the config file if/when
you want to change those built-in values... so the intention is to
gradually move options into there, so many instances of configuring
the system for a particular task would be possible simply by copying
the appropriate config file.  We could even put the NSUserDefaults
database into the config file for a system where you want to avoid
having a user defaults database but still want certain defaults
values to be used at runtime.  We also aim is to cut down on use
of environment variables  (we have already done that somewhat)
by putting them in the config file ... though where MacOS-X uses
environment variables we need to retain compatibility.