Re: Property List Format vs NSKeyedArchiver Format
Re: Property List Format vs NSKeyedArchiver Format
- Subject: Re: Property List Format vs NSKeyedArchiver Format
- From: Graham Cox <email@hidden>
- Date: Wed, 14 Oct 2009 11:40:26 +1100
On 14/10/2009, at 10:51 AM, Jens Alfke wrote:
While strictly true, it's not possible that Apple could really ever
stop supporting it, due to the many millions of files out there
that use it and will have to remain readable in their existing form.
True, but it can change in ways that are backward-compatible to
Apple's implementation. But reverse-engineered implementations might
fail to handle the updated format. I've seen this sort of thing
happen in the past in other areas.
There's still no way they could abandon the current format as it is
today entirely, because passing a newly written file to an app running
on an older version of the OS would break. At the very least it would
have to say "file x could not be opened", but it's a reasonable
expectation that archiving code written today would emit a backward-
compatible file when run on a future version of the OS. Thus even if a
much better (read, more efficient, less buggy) version of the keyed
archive format came along, NSKeyedArchiver would have to default to
the existing format to avoid breaking thousands of existing apps.
Developers could opt to emit the more modern format if they are
revving their apps for the new version of the OS, knowing that they
are cutting off backward compatibility by doing so - but it would have
to be opt-in.
I suppose it's conceivable that the format could change in a way that
is still readable by older dearchivers by taking advantage of known
implementation quirks, and that could break alternative
implementations, but since the older format would still have to be
correctly dearchivable as well, as long as your implementation wrote a
correct file in the older format, it would be forward compatible,
which is at least as important. I would imagine that format changes
that could slip through the implementation cracks of an older
dearchiver would be necessarily very minor, and hence probably of very
little value. Also, would they risk it, given that there already could
be alternative dearchiving implementations out there they don't control?
That's without considering the cross-platform issue (or rather, seeing
a new version of OSX as a different platform). Writing out the format
to disk effectively freezes the implementation in place for all time
(for at least a reasonable definition of 'all time'). If Apple did
break keyed archiving either forward and backward compatibility there
would be a huge outcry. There have been outcries over much less; I
just don't think it's even slightly likely that they would contemplate
doing it. Sequential archiving is still supported for exactly this
reason. Surely the attraction of using keyed archiving for saving is
that we can safely assume Apple ain't going to be messing with it? If
there's even a remote chance of them doing so, it would mean that no
developer would risk using it for fear of having their files break
randomly at Apple's whim.
I guess one reason I'm harping on about this is that my current app
does write the main data component of its files as a keyed archive
(the user can choose XML or binary versions) but at some point we do
vaguely plan to allow it to be opened cross-platform, by writing our
own dearchiver for the XML version, much as the OP is considering.
(And doesn't the XML format option exist for exactly this purpose?
Otherwise why bother as it creates a much larger file than the
binary). If there's no reassurance that it's a safe strategy, then we
may as well consign keyed archiving to the dustbin as an unsafe
technology. Since that just doesn't seem reasonable, the conclusion
must be that the format will always remain readable forwards and
backwards.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden