Re: NSKeyedArchiver implementation...

[Adrian Robert]

> Sorry, but my feeling is that this proposal would mean "lets do our 
> own stuff now and care for Apple compatibility later", that is never. 
> My question here is, what good would keyed archiving be, if it doesn't 
> allow the exchange with Apple applications? Our current archiving 
> format works quite well. Using XML in itself is by no means better, it 
> just uses up more disk space.

Am I wrong or is the on-disk format issue a different one from keyed- 
vs. non-keyed archives?  Keyed archives are good AFAIK for better 
forward/backward robustness against class changes than non-keyed, 
regardless of how things get written to disk.

Does Cocoa tie keyed archiving explicitly to an XML on-disk format, or 
do they just use XML on-disk for all archives now and since keyed 
archiving is a Cocoa addition it is "associated" with XML?

Somewhat related to this topic, Sun's XML serialization for Java 
approaches the robustness issue in a different way. 
(http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html)  
It centers on setter/accessor calls rather than variables.  Wouldn't 
work for GNUstep absent the Javabeans conventions used in Java but 
interesting nonetheless.


> And finally, once more the call for help:
> Could somebody with access to a new Apple development environment help 
> with decoding the bit fields? No actually programming skill is needed 
> here, just access to the IB and an editor. Of if even this is asking 
> to much, I am willing to write a short application to test the bits if 
> somebody will execute it and send back the results.

I have XCode et al. on the latest Panther, but haven't used it much; if 
you can let me know what to do I can probably help here.