[Top][All Lists]

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

Re: Keyed Archiving and MOSX compatibility...

From: Richard Frith-Macdonald
Subject: Re: Keyed Archiving and MOSX compatibility...
Date: Thu, 25 Mar 2004 20:44:32 +0000

On 24 Mar 2004, at 22:52, Gregory John Casamento wrote:


I believe that the current effort to make keyed archiving might cause massive changes in the way .gorm's are loaded, particularly with internals of certain
classes as well as the custom class templates.

Yes and no ... keyed archiving as such has absolutely no effect on gorm and gorm files, trying to make gorm files readable by interfacebuilder and/or
interfacebuilder files readable by gorm is another matter and may well
require massive changes as you suggest.

While, I believe our template system is similar, it is not the same as the one on MOSX and it is, in some ways, better. We need to make certain that these
classes are minimally impacted by this change.

I think they only need to be impacted as much as you want them to be impacted :-)

My intent when I suggested that we implement keyed archiving was to be able to get XML output for .gorm files, whether that was MOSX compatible or not.

Sure ... you can use keyed archiving for gorm files without attempting to make them macosx compatible. I don't know if everyone wants to stop at that point though (I'm not particularly bothered). The one thing I would suggest is that specific
keyed archiving code for the gui classes of the MacOS-X API (rather than
internal classes used by gorm such as template stuff) be written to be MacOS-X compatible so that if/when someone wants to write a gorm add-on to read or write interface-builder compatible files, they can do so without having to change
the keyed archiving code of the gui elements.

I beleive it is well worth the effort to try to make GNUstep and MOSX
compatible in this way, but I also believe that we shouldn't massively impact
current functionality to make it happen.

I am going to continue to look at how this can be done in a way that satisfies
all of our requirements. :)

I don't understand why there is a concern about impacting current functionality at all ... the keyed archiving stuff is all new and should have no impact on current functionality at all. The only impact I can see is - a little code added to the codebase and the runtime overhead of testing to see whether keyed archiving or traditional archiving should be done in -initWithCoder: and -encodeWthCoder:
I would expect that runtime overhead to be unnoticable.

If you are talking about how to make gorm and interface builder file formats compatible ... I think that's likely to be tricky and not easy to do without substantial changes to gorm, though I guess in principle it's possible to
have a module to read a .nib and translate the results into the sort of
structure that gorm uses internally, and similarly to have a module to
write a .nib from gorm ... thus leaving current gorm internals unaffected.
Sounds like too much work for me to want to try it though.

reply via email to

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