gnustep-dev
[Top][All Lists]
Advanced

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

Re: Release schedule


From: Richard Frith-Macdonald
Subject: Re: Release schedule
Date: Thu, 3 Apr 2003 09:56:18 +0100

Argh ... nowadays it seems I'm too busy at work etc to do anything like as much work on GNUstep as I'd like, and I'm certainly too busy to spend a lot of time on mailing list debates, but this thread just seems to keep going, so I guess I'd better at least state my opinion, though I don't want to get into the debate.

1. I think Nicola is right to say that the old/existing mission statement is OK, and it shouldn't mention stability... The word 'stability' has different interpretations, but I think the useful ones can/should be taken as a given aim and should not need stating. The extreme form, where nothing ever changes, bugs are never fixed, and the software is never ported to other systems for fear of breaking things is obviously a bad thing. The existing statement already says that we will not remove the OpenStep APIs even if apple does!

2. Personally, I do not like the horizontal MacOS menu bar, and don't approve of the new gui classes associated with it. I don't think that most of the new MacOS-X gui classes are good, and I'd quite happily see a standard GNUstep user interface guideline document included with the gui library advising you not to use them ... and providing examples of how to achieve similar/better results using the 'main' API. Then people who want to work on them can, and they would be available as an aid to porting apps from MacOS-X. In the base library I added an Additions library for stuff MacOS-X users would need to port GNUstep code to MacOS-X. This code is automatially incorporated into the base library but can be built standalone on MacOS, It might make sense to add a MacOS library for people who want it to supply MacOS-X classes which we *don't* want in the GNUstep base (eg apple scripting) ... these wouldn't be incorporated into the base library, but would be available for people who wanted them. We could do the same thing in the gui library ... with one area for classes that MacOS doesn't have, and an area for classes that MacOS has and we don't normally want. All that being said ... I don't really feel that this is a big issue ... I already feel quite free *not* to use MacOS-X classes if I don't want to, without having them separated into another library.

3. The OpenStep/OPENSTEP4.2/MacOS-X API argument that seems to keep being raised with regards to stability is IMO almost completely bogus. Application problems are not due to changing API so much as changing implementation details. All three suggested APIs are incompletely documented and ambiguous in places, so the most common application breakage (apart from bugs I guess) is down to changes in undocumented parts of the API. Saying we will conform to one particular documented API (we already say we will conform to OpenStep) does not have any effect on this issue. Saying we will conform to the implementation of OpenStep is impossible ... developers don't have a reference implementation to test against. Saying we will conform to the implementation of OPENSTEP4.2 is practically impossible ... most developers don't have a reference implementation to test against. So realistically, we only have the choice of testing undocumented/ambiguous parts of the GNUstep API against the MacOS-X implementation or just going our own way and probably being incompatible with both MacOS-X and OPENSTEP. Testing against MacOS-X at least gives us a good chance that our code will also match OPENSTEP implementations.

4. Stability in general ... of course we have a stable (OpenStep) API, but as I pointed out, that's of limited use in practice. I consider the base library stable on GNU/Linux ... in that it's as stable as any other (non-dead) system out there (certainly as stable as the Apple Foundation). It's really only just becoming stable on windows. Most changes are bugfixes or optimisations. Even the gui library is pretty stable in terms of what it's trying to do ... it just needs a lot more bugfixes to be contributed!!!
Most application problems I see are simply either -
a. Bugs in the libraries which need fixing and are unrelated to API specifications or project aims
or
b. Application passing invalid arguments to methods (or depending on undocumented behavior) and being surprised when the behavior changes due to internal bugfixes or improvements in internal consistency within the libraries. We can improve (a) by fixing bugs, and we can improve (b) by not fixing bugs :-)
Actually, the best thing for (b) is to improve the documentation.
IMO we should -
first, locate ambiguities in the documentation
second, check that the GNUstep implementation matches MacOS-X in ambiguous cases third, ensure that the GNUstep documentation says what the actual behavior is, and/or says that it should not be relied upon as we may want to change it to track MacOS Of course, this is a long slow process and needs people to do it rather than just talk about it.





reply via email to

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