Re: Release schedule

[Nicola Pero]

> OPENSTEP(/OpenStep) provides the base for this. It gives us a wonderful
> language in objective-c, a consistent philosophy in the interfaces and
> surrounding things, and a wonderful set of interfaces and behavior in
> FoundationKit and AppKit. However, it is not perfect; in some areas, well
> designed additions are good, in some cases even changes, and in extreme cases
> even removals (consider NSCStringText).
> 
> I want to be committed to maintaining this in the form of the FoundationKit
> and AppKit interfaces, updated with great care and thought, and a free
> implementation of them.

COCOA(/OpenStep) is a similar base.


> I see Cocoa-compatibility as a hindrance to this. Apple is a commercial
> entity, and is committed to entirely different things. While a few of  their
> additions are good, they have already made many additions and changes that
> are, at the very best, questionable. Committing ourselves to tracking these
> changes is folly: Every interface change means more compatibility problems
> for existing apps. Every addition is another set of classes and methods that
> we are committed to implement, regardless of technical merit, appropriateness,
> or feasibility.

Interface changes in future Cocoas are expected to be limited, because
Apple itself has to maintain backwards compatibility with previous
versions.

We can be selective, as we have always been, in choosing what to implement
and what not to implement of the additions.



> (do you really plan to implement things like AppleScript, Quartz,
> or NSQuickDrawView and NSMachPort?).

AppleScript can be implemented as a separate framework if anyone wants it.

Quartz on Cocoa is the equivalent of DPS on OPENSTEP - we don't plan to
implement DPS, and we don't plan to implement Quartz.  Not that they
wouldn't be both nice.

NSMachPort was already there in OPENSTEP I think.

NSQuickDrawView of course we don't care about - it's based on Apple
proprietary technology - it simply doesn't make sense for us.

I frankly fail to understand why AppleScript, Quartz, NSQuickDrawView or
NSMachPort are relevant anyway to API stability.

If your application is not using them, then why do you care if they are
there or not, or if their API changes or not ?



> Every bit of functionality added in Cocoa is a bit of functionality we won't 
> have the
> freedom to do a better job with.

It's not that easy - if you take that route you can easily end up
reinventing the wheel (actually, an incompatible wheel) every time.

It's a more delicate balance I think, between attempting compatibility
(which is good), and still attempting to implement a great system (which
is again good), and still attempting to make few changes to the existing
API (which is again good).

Ruling out compatibility from our goals in that way means we will go on
inventing our own incompatible API for everything ... which seems a poor
choice.



> Nicola: If Cocoa were to add a system for defining auto-layouting,
> localizable interfaces in an xml format, would you ditch Renaissance?
> Regardless of the quality of the Cocoa system?

We would need to know exactly what the Cocoa system does.  Being open is
generally a good thing.



> Even should we succeed in tracking Cocoa, we would only be as good as Cocoa,
> no better.

GNU is better than the average Unix, yet it has always been attempting to
be compatible with it.