[Top][All Lists]

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

Re: Release schedule

From: David Ayers
Subject: Re: Release schedule
Date: Thu, 03 Apr 2003 14:40:29 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Nicola Pero wrote:

<p>Note that it is not the responsibility of the main developers to
achieve or maintain Cocoa compatibility!

This is one of most important statements in my view.

Btw - I would much prefer to have to maintain and achieve Cocoa
compatibility than OPENSTEP compatibility, since I have a Cocoa system, I
can find a lot of documentation/books on Cocoa, I can find a lot of people
willing to test things on Cocoa on the net, while I don't have an OPENSTEP
system, there is not much OPENSTEP documentation around, and it's
difficult to find people having an OPENSTEP system and willing to test
things ... and it will be increasingly more difficult as time passes.

I find this rather unnerving. If GNUstep will be free, superior, value added Cocoa rather than a free, superior, value added OPENSTEP then you are probably alienating a lot of the existing GNUstep user / developer base (including me, but as I'm a newbie to the developers, that might not count.). I do believe that being able to implement projects portable between GNUstep and Cocoa (like is a very important aspect for GNUstep. But I also believe it is more important to design a consistent API bases on a stable implementation.

I believe the reason why people are so reluctant about the Cocoa additions isn't because they make GNUstep unstable per se, but because they make it inconsistent. Any "living" project will change and cause potential instability. I don't think that is an argument to refuse these additions. But Cocoa was created to "squeeze" OPENSTEP into the Mac environment and has been "patched" with featurisms that are partially inconsistent with the original design (probably quick and dirty hacks to allow legacy mac code to be ported to Cocoa more easily). But also there are meaningful additions that are worthwhile adapting as well as added restrictions to "force" explicit programming techniques. The problem is, that when we talk about Cocoa, we mean all of the above lumped together, each with a difference emphasis.

On the other hand, there are real OPENSTEP based implementations that simply don't work with GNUstep (yet?). In fact I work for a company that seriously considered porting a set of OPENSTEP based apps to GNUstep. Yet the project is rather large, with a lot of "nib-knowledge", windows based and has other design problems that this will probably not happen. But I'm sure there are others out there wishing to port who are tracking GNUstep, especially for the win32 platform. Plus a lot of ObjC based WO 4.5 project maintainers tracking GDL2 and GSWeb.

I think the right approach is to hand pick the features from Cocoa which we want to implement, publicly mention those on our website. Also identify those features which we don't want and publicly state that, as we already do for the scripting extensions. Yet even then we should note that we may consider accepting extension libraries which do implement these feauters as long as they are maintained by someone against current versions of core.

I don't find it important that there is 'a lot' of documentation on OPENSTEP around (even though there is quite a bit). The problem is, that we don't have *sufficient* information *publicly* available. And here I agree with you that this is an issue. The API documentation that was part of the original NeXT/Apple distribution was mostly consistent and this was an important factor of why many developers found it so intuitive to develop on this API and feel so strongly about it. But we don't have it publicly available and it is insuficient to implement a compatible system.

Maybe the time is ripe for the tedious "official" GNUstep documentation of it's OpenStep implementation. But for true portability, we still have to bite the bullet. Neither the OpenStep specification nor the OPENSTEP 4.2 documentation are sufficient for an unambiguous compatible implementation (by this I mean the formal API including the behavior which projects generally rely on). So we need a more complete documentation. But the only way to attain this is tedious testing on an OPENSTEP implementation and understanding and evaluating the concepts to gain a consistent solution. This can be done for various parts with differing complexity. Where we find that a different approach is more applicable, we should add GNUstep specific implementation (i.e. a potential GSMenu-System) and use this as the default. But also provide a compatible implementation (NSMenu system) for apps that need this and wish to be portable.

Doing this for Cocoa would be more tedious and volatile, as I'm sure in time they'll notice their flaws and keep adding new features and deprecating others. Yet I admit that this system is more wide spread, has documentation availble online. But is something close to sufficient for implementing a compatible system anywhere?

So we need people with OPENSTEP and interest in OPENSTEP compatibility to come forward, port our reg-testing framework (which happens to be guile) and start testing the API's guts. People with Cocoa should also do it there. Then we need a mechanism to handle discrepancies. One day we may have to decide whether to take the OPENSTEP or the Cocoa route. But are we really there yet?

I think the problem might lie just in need for a defined process of handling this. I would volunteer to supply any needed tests I could do on OPENSTEP Enterprise, if I weren't wound up in GDL2 currently. (I'd have a NEXTSTEP 3.2 at home also... but maybe I'll look for an OPENSTEP 4.2 for Mach) I'd still be available for specific defined tests (I can't help much with the menu system of OPENSTEP 4.2 for Mach though.), but I'm not ready to port guile especially as there might be considerable trouble on getting MinGW and OPENSTEP Enterprise to work together. Maybe a switch to an ObjC regression testing framework would be necessary. (Hmm... on second thought, I wonder what happens if I compile guile sources with ProjectBuilder on OPENSTEP Enterprise...)

GNUstep is already more and different than the OpenStep spec. So the question boils down to
a) Do we aim at OPENSTEP 4.2 compatibility only
b) Do we aim at Cocoa current compatibility only
c) Are we able to do both (and should both be available in one set of compiled libraries.)

I think we should aim at c) and we should focus on implementing things in a "consistent" form in the scope of GNUstep first (possibly GS-specific) and then add OPENSTEP and Cocoa compatibility. I'm not sure how many incompatible discrepancies there really are. We might need to separate these compatibility features into separate loadable modules, similar as we did with the gui back end or some similar mechanism. But I think c) should be our "official" goal and conflicts should be resolved on a case by case basis, independent of the resources of individual developers.

As long as we have people willing to test against OPENSTEP, we should support it. Maybe those people who want OPENSTEP support and have access to OPENSTEP implementation should interpret this as a cue to join in.... Like I said, I'll be available for more intensive testing as soon as things with GDL2 and GSWeb quiet down. But I'm willing to do defined tests anytime.


reply via email to

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