Many applications use extended attributes (xattr) for similar purposes. The oldest way that still works is to use the resource fork of a file, which is sometimes implemented as an xattr. In these cases, for those file systems that support them, they are intrinsically part of the same file.
- Gary L. Wade (Sent from my iPhone) On Aug 28, 2011, at 12:42 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote: > Dear list, > > I've been scratching my head for a while on this. Suppose you have an > NSDocument app like TextEdit which just allows the user to edit a text file. > Now suppose there are some additional state settings associated with the > editor. These could dictate how the contents of the text file are displayed, > or how some other actions are to be carried out. My question is, where is the > best place to store these additional state settings so that they persist > across restarts of the app. I can think of 3 ways, and I don't really like > any of them: > > 1) encode the settings as a string and tag it on the end of the text file > then parse that string out when the file is reopened. > 2) write an additional plist file next to the text file on disk, perhaps with > the same name or as a hidden file. > 3) write a plist file in the application support directory > > Thoughts: > > Method 1) sounds fragile and painful to implement and maintain > Method 2) sounds intrusive - I don't like the idea of sprinkling files on the > user's disk > Method 3) would mean the support directory fills with plist files which may > never be used again > > Anyone got any better ideas? Perhaps I'm missing something very obvious > here..... > > Cheers, > > Martin > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Hewitson > Albert-Einstein-Institut > Max-Planck-Institut fuer > Gravitationsphysik und Universitaet Hannover > Callinstr. 38, 30167 Hannover, Germany > Tel: +49-511-762-17121, Fax: +49-511-762-5861 > E-Mail: martin.hewit...@aei.mpg.de > WWW: http://www.aei.mpg.de/~hewitson > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
