Re: Release schedule

[David Ayers]

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 GNUMail.app) 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.

Cheers,
Dave