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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev