|Home » Learning Curve » Developers Workshop
Document Specific Extended Attributes
User friendlier at no cost to anyone.
Starting with the 29 September release all ACP applications support extended attributes on a per-document basis.
The advent of OS X and the return of Steven Paul Jobs to Cupertino meant the resident corporation started using an entirely different operating system. Much effort was expended to disguise this rift - as evidenced still today in the panicky blogosphere - but the change was total and older technologies remained in name and no more.
Technical note TN2034 spelled it all out - and caused the fanboys to break into hysterics. But the fact remains that despite ornery critters such as the AppleDouble construct certain things are better left on the native platform and others that can't be transported easily should either be incorporated into mainstream data storage or abandoned completely.
And whilst resource forks per se may not be a thing of the past legacy resource fork APIs are - they're officially deprecated today and as of tomorrow (Leopard) will be permanently held in 32-bit quarantine until they're long forgotten.
And whilst Apple today deign to store 'metadata' on a per-user basis (in a single store located in root for all users) the idea of taking advantage of additional file forks for something else has not been looked into before now.
Apple's 'Unix' API for extended attributes allows setting arbitrary data for any arbitrary attribute: name the attribute and give it some data and it goes into the volume extended attributes file - how this is implemented by the underlying file system (HFS) is not important; that it's a 'legitimate' API is.
The 'MacOS' resource fork APIs have been deprecated but for now are still supported. They've been superseded by extended attribute APIs. Even 'file info' / 'folder info' - commonly referred to as 'Finder info' - is accessible through this new (for Tiger) API. There are of course certain constraints on their use (and there are still some bugs in Apple's code) but they will peacefully coexist with whatever other extended attributes are attached to a file.
And in order to avoid conflicts they use the names com.apple.FinderInfo and com.apple.ResourceFork.
A comparable method - now used by Rixstep's ACP - is to attach extended attributes as needed on a per-document per-application basis using the client application's bundle identifier. This allows attaching separate extended attributes to the file for use by alternate editors/viewers.
Thereafter it's up to the individual client applications to decide what to use this data for. In the case of applications such as Rixstep's Xbase column widths, sorting order, and sorting direction are stored. Another application also using the same file can also attach attributes in the same fashion - and because of the namespace convention there's no risk of conflict.
Client applications assemble a property list of data they wish to store and request the service from the ACP Framework; when starting up they can request this data back again. The ACP Framework figures out who they are, computes the attribute name, and gets or sets the property list accordingly.
Rixstep: The ACP
Rixstep: The ACP Framework
Rixstep: The Chocolate Tunnel
Rixstep: CLIX, CSV, DSV, ESR & the Meaning of Life
Rixstep: Oh Where Oh Where Did My Resource Fork Go?
Postscript: Another Tack?
|FROM : Sanford Selznick|
DATE : Sat Sep 29 17:34:14 2007
I have a set of preferences that display in a sheet on a document window. The preferences are saved /for/ the document on that machine, but not /in/ the document itself. Each of my documents contains a UUID I can to use to key the preferences for that document.
I'd like to use all the goodness of NSUserDefaults and IB bindings to set the controls on the sheet. Perhaps with some sort of dictionary in the NSUserDefaults for each document? How do I specify this dictionary as the defaults for the sheet?
I've read the archives, Apple's documentation and I don't quite see how to do this.