Re: "Jaguar" additions

[David Ayers]

OK, lets try this again....

>> I'm kinda trying to figure out just what the point of this is; playing
>> follow-the-leader is useless, in large part because there are huge areas
>> where "the leader" simply can't be followed, because of trade mark,
>> license, patent issues, or just the fact that they have a _lot_ of 
>> people
>> working on OSX full-time.
>
>Although I do agree on this issue, there's no reason to prevent people 
>from at least trying to catch up. Personally I do think that Zeroconf 
>isn't that important and other things (especially the GUI) have to be 
>pushed more, but then again that's just my opinion. If someone has 
>talent & energy in implementing the Zeroconf stuff, why not?
>
>But concerning feature-completeness: GNUstep wasn't feature complete 
>compared with Apple's Foundation long before Jaguar. Think about 
>Applescript and its extensions in Apple's Foundation. You won't find 
>them in GNUstep (thank God for that! ;-).
>

I do believe that it might be time to address this issue about NeXTSTEP / 
OPENSTEP / Cocoa I (OS X 10.1) / Cocoa II (OS X 10.2) compatibilty (again). 
GNUstep was "born" as an OPENSTEP implementation. It relied on a (more or less 
complete) open specification. Therefore NeXTSTEP compatibilty was never an 
issue. OPENSTEP has been dropped by by SUN and only GNUstep remained as an 
implementation with "much" OPENSTEP compatibilty, giving apps the chance to 
move away from Apple. (I dare say now with the windows frontend to GNUstep, 
especially window's apps still using OPENSTEP Enterprise have a way out. Thanks 
Fred!)  I guess you can say that OPENSTEP (as an open specification) has also 
been dropped by Apple and has been converted into Cocoa. The API has seen some 
serious development and GNUstep has been very succsesful in following suite to 
become relatively compliant. Apple did introduced some new "features" which 
seem objectionable for an cross platform API (which OPENSTEP was meant to be 
and GNUstep is).

I believe that it is time to clear up the smoke and clairifiy what GNUstep will 
strive to be in the future and publicize this explicitly on the web site. The 
issue is compatibilty. As I understand, GNUstep doesn't aim to be a "clone" of 
Cocoa but an alternative free implemetation with added features. Apple, in the 
meantime, has made Cocoa its primary API and claims to have the largest UNIX 
(TM) installation base. It seems very clear that the API will be subject to 
even more development in the (near) future. This will include features and 
clutter since a lot more people (or rather companies) will take an interest in 
it's development. How can GNUstep prepare for this? Is it at all feasable to 
try? Should OPENSTEP and Cocoa I compatibily remain?

I don't know. But I believe there might be a way to make (most) everyone happy 
(I'm not sure how well it would work though). But here it goes: Keep the main 
core libraries (base / gui) compatible with Cocoa I/OPENSTEP (4.2?) (keep using 
#ifdef's to differentiate.) Add only the features that seem to fit in well. 
Introduce compOSX libraray which contains the extensions and perhaps catagories 
if the behavior of objects actually change (which should be expected.) Then 
there might be a (header/#ifdef) mechanism to select the requested compatible 
version when code #imports <AppKit/???.h>). With each new release of Os X 
comp0SX would be branched, the main line would aim to fit the current version, 
while the branch would be open for bugfixes of the older Version.

This would meen that the compOSX libarary would be chasing OS X (which has lots 
of developer resources which GNUstep doesn't have) yet I believe compatibility 
is major issue. On the otherhand, those not really interested in the whims of 
Apple could rely on a stable GNUstep API and use the extensions libaray or what 
ever.

I know this sounds good in theory, and that the real problems arrise once Apple 
really starts messing with core-Foundation mechanisms (which I hope hasn't 
happend aet), but I believe it provides a simple clear stucture securing 
stability while aiming at compatibilty with the option to bail out if it turns 
out to be too tedious to follow suite.

In any case, It would be great to see a clear strategy statement of what 
GNUstep will aim for.

Cheers,
David

PS: Considering that Nicola is out of town right now, maybe this should be 
postponed until he returns., but maybe we can collect some ideas in the 
meantime.