Re: NSKeyedArchiver implementation...

[Gregory John Casamento]

Guys,

My apologies for the grammatical mistakes in my previous message.   Sometimes
when I write in a hurry I inadvertantly skip over certain things. :)

GJC

--- Gregory John Casamento <greg_casamento@yahoo.com> wrote:

> Richard,
> 
> --- Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> 
> > 
> > On 9 Sep 2004, at 19:45, Richard Frith-Macdonald wrote:
> > 
> > >
> > > On 9 Sep 2004, at 19:13, Fred Kiefer wrote:
> > >
> > >> At first I thought of this as a very nice solution, doing our own 
> > >> stuff, while still being able to exchange with Apple applications 
> > >> would be great. It would even free us of update problems for either 
> > >> side, as incompatible changes would just result in small changes on 
> > >> the XSLTs.
> > >> Than I tried to imagine an XSLT for this and here my fantasy failed 
> > >> me.
> > >> So for example how would you transform any of the actual problematic 
> > >> bits you listed above?
> > >
> > > Yes, my feeling too ... I would expect that producing archives in a 
> > > new gnustep specific format and trying to use xslt to convert between 
> > > that and macos-x format would be a *LOT* more work than just using the 
> > > macos-x format to start with.
> > 
> > It occurs to me that it may not be obvious why this is so ...
> > 
> > If we want macosx compatibility at the end of the day, we have to 
> > reverse engineer the macosx format in order to understand it.  This 
> > work is required irrespective of the format we use.
> 
> True.
> 
> > So what we are concerned with is how we translate between situations 
> > where the classes in macosx are not the same as the classes in gnustep, 
> > and we have to perform some complex mapping between them.
> 
> Yes.
> 
> > While xslt is very good for performing translations on simple xml 
> > element hierarchies, Objective-C is a much more powerful language and 
> > can more easily cope with complex situations ... not to mention that 
> > anyone writing this code *must* understand the objc classes in order to 
> > know what the translation should be, and so will be familiar with using 
> > objc (probably much more so than with xst|).
> 
> XSLT is good at pattern matching and translation.   It is much more natural
> for
> changing XML from one form to another than most other languages.    In that
> sense it's powerful.   There's no reason why it couldn't be used in the way
> I'm
> suggesting.
> 
> > Also, the macosx archive format (as xml) is not designed for easy 
> > translation using xslt (it's an xml representation  of a binary 
> > serialization of a property list)
> 
> I'm convinced that even though it's XML it was never designed for easy
> translation under any means.   We would, of course, need to unserialize,
> transform and reserialize.
> 
> > so while we could design a 
> > gnustep format to be easily handled by xslt, the translation would 
> > still be horribly complex.
> 
> I never once said that the translation would be any easier with XSLT than by
> doing it in the code.
> 
> My issue is that we will not only need to read, but we will also need to
> WRITE
> the same format.  So we *will* need to keep up with IB and Cocoa changes,
> which
> can only be done by those of us who have Cocoa machines.  This is
> particularly
> a problem when it comes to .gorm archives (which are just object archives
> like
> any other).  There are many internal classes which are vastly different and
> it
> will be expected that if keyed archiving can read/write Apple archives that
> we
> will also be able to read/write Apple .nib files (since they are also simply
> archives). 
> 
> There are some things that have been done in GNUstep, particularly with
> templates, which are superior to how Apple/NeXT implemented it on
> MOSX/OPENSTEP.   I hesitant to reverse engineer this piece on MOSX, and
> others,
> and change how we work and possibly degrade how we work simply so that we can
> be compatible.
> 
> GJC
> 
> =====
> Gregory John Casamento 
> -- CEO/President Open Logic Corp. (A Maryland Corporation)
> #### Maintainer of Gorm for GNUstep.
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 


=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A Maryland Corporation)
#### Maintainer of Gorm for GNUstep.