• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Migration Path for NSArchiver data?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Migration Path for NSArchiver data?


  • Subject: Re: Migration Path for NSArchiver data?
  • From: Colin Cornaby <email@hidden>
  • Date: Thu, 19 Apr 2007 10:45:42 -0700

The only issue (without going into NDA'd specifics) is that Apple has stated we should move away from deprecated API's for 64 bit:

http://developer.apple.com/leopard/overview/apptech.html

"Most applications won't need to make the jump to 64-bit yet. However, there's no reason not to be ready to move an application to 64-bit in the future. To ensure that you are ready, you'll want to be sure that you write your code in a manner that's easier to move to a 64-bit later future. The best way to do this is to move away from deprecated APIs, such as QuickDraw, and adopt the use of the new NSInteger and NSUInteger data types that are used throughout the system frameworks in Leopard in place of int and unsigned int. By doing these tasks now, you'll have much less work to do later."

In since the code in question is a framework, I'd like to make it 64 bit in order to enable 64 bit applications to link against it.

On Apr 19, 2007, at 1:47 AM, Uli Kusterer wrote:

Am 19.04.2007 um 06:42 schrieb Colin Cornaby:
Is there any method for reading NSArchiver data after NSArchiver drops off the face of the Earth? It seems odd to me there is no plan to deal with already NSArchiver serialized data out there.

It isn't likely that NSArchiver will drop off the face of the earth. My impression is that it's deprecated for use in writing new code, because keyed archivers automatically do most of the versioning for you if you know how to handle NIL keys. Apple might also not port it to new platforms (if they ever do another major platform move). If you look at NSUnarchiver, they actually still have a call in there that reads some of the old NX-objects. If they still support reading pre-Cocoa objects, chances are they'll throw that out *before* they throw out NSArchiver.


That said, nobody knows Apple's plans. So, all of Cocoa or Carbon could disappear off the face of the Earth in a future system version and you wouldn't be able to use it anymore. If you want to be safe from that, invent your own format and use that. Otherwise, just hope that Apple stays this nice and generally gives us years' worth of warning before they drop an API. Since you're writing your data, you would probably also have not many problems just looking at some files you generated and "reverse-engineering" the file format for your particular case, and write your own NSUnarchiver.

Think of the GNUstep folks if you do that, they might have use for that code, too. Or someone there might already have written it.

Cheers,
-- M. Uli Kusterer
http://www.zathras.de




_______________________________________________

Cocoa-dev mailing list (email@hidden)

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


References: 
 >Migration Path for NSArchiver data? (From: Colin Cornaby <email@hidden>)
 >Re: Migration Path for NSArchiver data? (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: CG related warnings when loading Nib
  • Next by Date: Re: Detecting networks programmatically
  • Previous by thread: Re: Migration Path for NSArchiver data?
  • Next by thread: [Cocoa] How convert ":Developer:Private:jam" into a path POSIX-style
  • Index(es):
    • Date
    • Thread