|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.
Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.
All Material and Software © Rixstep All Rights Reserved.