Hi Uli, thanks for your in-depth response!
On Aug 28, 2013, at 20:38 , Uli Kusterer <witness.of.teacht...@gmx.net> wrote: > On Aug 28, 2013, at 4:53 PM, Marcel Weiher <marcel.wei...@gmail.com> wrote: >> does anyone have practical experience with the forward/backward >> compatibility aspect of keyed archiving? That is define a file format using >> keyed archiving where backward and forward compatibility was both desirable >> and achieved? > > I've written code that was supposed to be future-safe with NSKeyedArchiver, > and I've written raw binary file access code that was future-safe, but the > archiver code I wrote hasn't actually been tested in practice AFAIK (i.e. I > never got to see incompatible changes being made). So while I can give you > the practice of writing the code, I can't actually confirm that it's bug-free. That was exactly the sort of experience I was looking for. I myself have also tended to go for externally defined file formats, and the (old-style) archiver-based format was with a version number (and yes, no version number means “Version 1” *g* ). > [good description of how to accomplish versioning with a keyed coder] > If you did your own binary writing code, you'd probably only need one version > for the entire file. However, keyed archiving is encapsulated, per-object. > You can have objects from various frameworks, each of which can change > independently. This is a good, clean design, but means you need to save the > version again for each class. Seems about right to me, though the documentation claims different: "A keyed archiver does not encode class version numbers." > [more on class versioning] > You can't really use keyed archivers if you want to be able to open and save > the new file format with an old version. That was my impression as well, though again the documentation claims different. And of course, the one “key” application of keyed archives, nib file loading just doesn’t have that problem: as you’re shipping code and data together, you can ensure that they are compatible, and the nibs are compiled from XML anyway. > [what data to keep or throw away] > Also, if you add a new class, the old application won't be able to > de-serialize it from a keyed archiver. Hadn’t thought of that one! Er…I meant to say “completely obvious!!" > However, keyed archivers work if you only need to be able to open files > created by the old version in a new version of the app. Which you can have just as well by not deleting the old unarchiving code that you presumably already have. So the whole automagic forward/backward compatibility that we’re supposed to get with keyed archives doesn’t actually pan out. If you want compatibility, you have to plan and code for it, just like with old-style archiving. And ideally, you have an externally defined format. That was sort of what I had been thinking, and as we all know there is no difference between theory and practice :-) Thanks again! Marcel _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
