Re: Keyed Archiving and MOSX compatibility...

[Richard Frith-Macdonald]

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

> All,
>
> 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.