[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)
From: |
Kazunobu Kuriyama |
Subject: |
Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision) |
Date: |
Fri, 23 Jan 2004 02:43:47 +0900 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 |
Richard Frith-Macdonald wrote:
<snip>
Just to clarify my position ...
I definitely want the archiver format (ie what the archiver
reads/writes, rather than
what the encoding/decoding code in each class being archived does) to be
MacOS-X compatible ... so people can implement their own classes in
such a
way that they can have portable archives. I'm doing this.
I'll look into this again.
I would like implementations of keyed archiving code for library
classes to be
reverse engineered from Apple archives ... so that people can use library
classes when archiving their own objects, and still have portable
archives.
I think nobody is against this idea...
However, I'm not planning to do all that work on my own (though I might
implement some keyed archiving coding for base classes) ... as I feel
that
people who want this should really be prepared to contribute the code for
the classes they use themselves.
Yes, we can expect it. I'm not sure, however, whether or not the
contributors also
take responsibility for maintaining their contributed code and we can
take it for
granted. Because there are a lot of -initWithCoder:/-encodeWithCoder:
in the libraries,
I don't think we should overlook it.
I *don't* believe we should implement keyed archiving code for individual
classes which is not compatible with MacOS-X code for the same classes.
I'm afraid this scatters much code which is almost impossible to maintain as
a whole. The total number of the modified code would amount to 9,000 to
10,000
because the code will expectedly doubles (or more) when we add keyed
archiving
support to it. To address this problem, how about the following scheme?
(1) We implement each of iniWithCoder:/encodeWithCoder based *only* on
GNUstep's
internal structure. This makes implementation and maintenance faily
easier
because we don't need to care for Apple's at this level.
(2) All needed conversions from GNUstep to Apple and vice versa are done
within
archiveRootObject, unarchiveObject*, and their friends. In other words,
all differences between GNUstep and Apple is absorbed/encapsulated
in these
methods (or yet another class for this purpose may be possible).
This looks
making the implementation feasible because we could know
interrelation of
objects, or an object graph, from a resulting NSCoder, and thus the
conversions
being made easier (if possible). We could convert the NSCoder into
a new one
and use the latter for compatibility purpose. Also, we could change the
behavior through the system defaults, as you noted somewhere else.
I'm not sure this is really feasible, though. Just wanted to address the
problem.
We have had a keyed coding API in GNUstep pretty much forever ... but
nobody uses it as far as I know, so there is obviously not enough
intrinsic
value in keyed archiving that we should ignore the potential for MacOS-X
compatibility when writing coders for classes.
I feel we definitely need to distinguish archiving from serialization in
this
particular context because the former must take interrelation between
objects
into consideration but the latter not.
<snip>
I see archive compatibility for the library classes rather like api
compatibility ...
it's a good thing, and we should aim for it, but we know it's a moving
target
and can never be perfect. We can each decide how much time we want to
devote to it.
Before jumping into this conclusion, shall we give another chance to our
brains so that we can enjoy admirable laziness? I hope we can make it.
It has the nice characteristic that any work on it is highly isolated
from the rest of the code and can therefore be done with negligible
impact on people who aren't interested in it.
Absolutely.
- Kazunobu Kuriyama
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), (continued)
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Alexander Malmberg, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Ken Ferry, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Ken Ferry, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Kazunobu Kuriyama, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/22
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision),
Kazunobu Kuriyama <=