Re: Release schedule

[Chris B. Vetter]

On Wed, 02 Apr 2003 16:37:42 -0500
Tim Harrison <address@hidden> wrote:
> Chris B. Vetter wrote:
> > In my opinion (that is, I'm only talking for my person), core/
> > should be a straight forward implementation of Openstep (whatever
> > the correct spelling is ;-)
> I very much agree with Chris on this point.  It's stable, unchanged,
> and provides an excellently documented base to work from.
> If, for example, -base is, indeed, very much OpenStep compliant, it 
> wouldn't be too terrible to go through, pull out the non-OpenStep
> stuff, set it aside, and clean up the rest.

Precisely.

> > Once that is accomplished, it would provide a common foundation we
> > can then use to implement "enhancements" in form of Cocoa classes
> > and methods, as categories, bundles, whatever.
> As long as they add value to the end product, yes.

Uhm, I thought that was implied ;-)

VAS' (value added solutions ;-) like NSDrawer or NSToolbar (tho opinions
about those two might differ) and VABs (value added benefits ;-) like an
implementation of Rendezvous certainly would be of benefit to GNUstep.

> However, my hope would be that one could retain the STRICT_OPENSTEP
> option, or some equivalent, or be able to only use the OpenStep
> compliant part of GNUstep, without causing problems.  That way,
> applications ported from OPENSTEP, or an application built using
> GNUstep's OpenStep core/ would be sure to run everywhere, with
> predictable results.

If Cocoa related stuff was extracted from base/ and gui/ and placed in
a seperate, say, cocoa/ directory, you'd only need a compile time
option. Alternatively, the Cocoa header files could be wrapped in an
#ifndef STRICT_OPENSTEP ... #endif.

Provided, GNUstep-specific extensions, that are neither Openstep nor
Cocoa related, would also reside in a seperate subdirectory.

If you think about it, that would be a much uhm "cleaner" approach.

-- 
Chris