[Top][All Lists]

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

Re: NSKeyedArchiver implementation...

From: Richard Frith-Macdonald
Subject: Re: NSKeyedArchiver implementation...
Date: Fri, 10 Sep 2004 18:35:50 +0100

On 10 Sep 2004, at 14:00, Gregory John Casamento wrote:

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

Of course it *can* ... but I suggest you try using it for a few examples of the sort of situations where transforming between class layouts in ObjC is troublesome, and
I think you will see what I mean.

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.

I'm not sure what you mean by 'unserialize' ... the xml document is one
serialized form. The unserialized form is a network of objects in memory,
so a transformation of the unserialised for would be done in objc rather
than with xslt.

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.

Yes of course. That doesn't seem relevant to the issue of whether to use xslt or not though as we have to translate in both directions whatever formats
and tools we use.

 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.

Yes.  However, apple has to maintain compatibility in it's own nibs,
so that's not a major issue.

 This is particularly
a problem when it comes to .gorm archives (which are just object archives like
any other).

There is no reason why gorm archives should use NSKeyedArchiver ...
they don't do so now and they work fine. If you mean that the translation between nib and gorm formats is complex/difficult, I quite agree ... which is why it
needs to be done in ObjC if it is to be done.

 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

I think that's what people would like to see...

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.

The fact that there is work that needs to be done if gorm is to read/write apple NIBs
doesn't mean you or I have to do the work ...

I really think this is a non-issue -

If you want to be MacOS-X compatible, the work is inevitable.
If you don't want to be MacOS-X compatible, you don't have to do the work.

Nobody is demanding that you work to make gorm macosx compatible.

Fred and I have worked on macosx compatible keyed archiving as an
aid to general macosx compatibility should anyone wish to use it.
Nobody is forced to use it, but we don't want anyone to break it for others either.

reply via email to

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