Re: Archiving / Unarchiving Question
Re: Archiving / Unarchiving Question
- Subject: Re: Archiving / Unarchiving Question
- From: "Tony S. Wu" <email@hidden>
- Date: Thu, 02 Jun 2011 08:45:39 -0700
Thanks for all the suggestions. Dave was right, the class was not included in the server target (bang my head). Using XML, however, does seem to make more sense, so I will look into that as well.
Thanks a lot,
Tony S. Wu
email@hidden
On Jun 2, 2011, at 12:26 AM, Jens Alfke wrote:
>
> On Jun 2, 2011, at 12:09 AM, Kyle Sluder wrote:
>
>> Which is a good reason why you should not use archiving as a representation of your data.
>
> Well, I think archiving can make sense as long as the producer and consumer are the same application, and you know that the file/data format will never need to be made open, and no external apps will ever need to read or write the data. In that case the ease of implementation can be worth it.
>
> But if you have different apps involved, or the format needs to be documented, it’s clearly the wrong way to go.
>
>> Use an implementation-agnostic serialization format like XML or even property lists for data whose existence is not inextricably tied to your class hierarchy.
>
> For something with property-list semantics I’d be more inclined to use JSON than Foundation’s XML encoding. JSON is much more lightweight to parse, often more compact, and more readable for debugging. (Of course there’s unfortunately no built-in JSON API, but there are several good Cocoa ones like json-framework aka SBJSON.)
>
> Avoid the temptation to use the binary property-list encoding over a network. Yes it’s smaller and faster than XML, but I’ve still gotten no assurances that the parser is robust enough to handle bad data (corrupt or maliciously hacked) safely. Back in the day it was possible for bad binary-plist data to crash the parser. If that’s still the case, then reading binary plists from an untrusted source like a socket is a potential security vulnerability.
>
> —Jens_______________________________________________
>
> 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
_______________________________________________
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