Hello guys, I've recently started working on EtoileSerialize again, the objective being to make it support serialising objects that implement NSCoding. The code presently lives in my branch (thebeing/ESArchiving) and the archiving side of things is already looking good, and I'm going to write the unarchiving part over the next week. Unfortunately, this change is not entirely backwards-compatible. You can still deserialize object graphs written by old versions of ES, but not the other way around. Also, the object stores are as of yet unable to encode information about what version of ES the archives were created with (the binary backend does not even contain any magic number). That is why I'd like to propose breaking backwards-compatibility altogether and make additional changes in the following areas:
* Smarter stores: Object stores should be able to carry metadata about the ES/backend version they were created with, which backends they can be used with (and which is the preferred one). * Overhaul the binary backend: Presently it stores data in a machine-dependent format, but it really should encode stuff in an independent format. * Reconsider the relationship with CoreObject: I'm curious to see whether we can somehow integrate the automatic persistency from ES with Eric's new more informed approach to versioning/merging. (e.g. how does it relate to branches/versions in ES object stores?) And while I myself am a bit clueless about that, I really thing we should have a strategy here. Since we probably don't want to break the format ES uses very often, I'd be really interested to hear your opinions on the matter (questions? further suggestions? issues?) Cheers, Niels _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
