[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)
From: |
Gregory John Casamento |
Subject: |
Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision) |
Date: |
Wed, 21 Jan 2004 20:02:42 -0800 (PST) |
Kazu/Richard,
--- Kazunobu Kuriyama <kazunobu.kuriyama@nifty.com> wrote:
> Richard Frith-Macdonald wrote:
>
> <snip>
>
< snip >
>
> This is the point I'd like to make sure of. Does "be MacOS-X
> compatible" mean that archives resulting from the new GNUstep's
> keyed archiver could be used with both GNUstep and MacOS-X, or,
> its format (e.g., the names of keys) would be merely the
> same as that of MacOS-X?
For full compatibility all information in GNUstep archives would need to
precisely mirror the information archived by Apple.
> If it means the latter, the work for modifying
> initWithCoder:/encodeWithCoder:
> is expected to be tedious but straightforward.
>
> For the former, however, these methods must inherently know the mapping from
> a GNUstep's object graph to the corresponding MacOS-X's one and vice versa,
> which I think is the point you suggested when you replied to my note on
> the statistics. Dealing with the mappings leads to the problems Gregory
> pointed out.
I've said enough on this point in previous mails.
> Though I rather prefer the former compatibility if possible, I'm not
> sure how
> the difficulty is overcome. That's why I made a bitter compromise from the
> beginning. Too soon to give it up?
We should at least look into it to see what the challenges are, in addition to
those that I've mentioned.
> > If there is a pressing need for keyed archive support to be added to
> > a class in a non-macosx-compatible manner, the incompatible version
> > could be controlled by the user defaults system. My guess is that
> > this would rarely be necessary ... but that is just a guess, I don't
> > think
> > we will really know until we try writing new coding/decoding stuff.
>
> I don't think anybody likes an avoidable non-compatiblity. IMHO, the
> problem
> is rather a matter of feasibility and maintenability.
Yes. This is my major concern.
> > So as far as I can see, adding keyed archiving gives us the opportunity
> > to move towards portable/compatible archives without breaking any
> > existing stuff.
>
> Indeed, it's a good opportunity.
Later,
=====
Gregory John Casamento -- CEO/President Open Logic Corp.
-- bheron on #gnustep, #linuxstep, & #gormtalk ----------------
Please sign the petition against software patents at:
http://www.petitiononline.com/pasp01/petition.html
-- Maintainer of Gorm (featured in April Linux Journal) -------
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
- 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 <=
- 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, 2004/01/22