[Top][All Lists]

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

RE: XML idea

From: Mondragon, Ian
Subject: RE: XML idea
Date: Wed, 07 Jan 2004 09:49:54 -0600

just my 2 cents (or maybe 1.5, given my incognito-ism as of late):

while i understand that GNUstep's stated mission revolves explicitly around
the openstep spec, it goes without saying that:

1. with OS X, the openstep spec has been updated for more "modern"
development needs
2. while cross-platform concerns run rampant, the most tantalizing tidbit is
the ability to compile a
designed-with-GNUstep-in-mind codebase on OS X, and vice versa (with nibs
being the remaining issue)

so my vision of what would benefit the GNUstep community the most would be a
codebase that contains implementations of the OS X (or "Cocoa", depending on
how cute you want to be) classes as best we can, where applicable.  this, as
helge points out below, would obviously exclude implementation of
AppleScript-specific classes...unless someone wants to make some sort of
nifty haque here that i don't really want to imagine.

perhaps in the near future, a list could be committed to CVS as mentioned
below to keep track of what is and is not implemented to encourage us to
contribute more to the core codebase and help keep discussions like this
short and sweet.

- ian

-----Original Message-----
From: Helge Hess [mailto:address@hidden
Sent: Wednesday, January 07, 2004 7:57 AM
To: GNUstep discussion list
Subject: Re: XML idea

> If it's in additions, you should be able to use it in MacOS-X either 
> natively or by using the additions library.

I'm only interested in things which are available on MacOS-X natively.

> I really don't think you can produce a definitive statement on new 
> MacOS-X features ... they keep changing.

So there should be a procedure on how to deal with that. Eg I think 
there is some agreement that AppleScript things are not being added to 
gstep-base. Probably we need a 
supported/optional/unsupported/not-yet-implemented list.

> Some we might want to incorporate directly into the base library 
> (probably most changes to existing classes and new classes we think 
> are really well designed), others we might put in the additions 
> library for compatibility but not treat as 'core'.

reply via email to

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