Request for an updated document typing/ownership model

Number:rdar://5909813 Date Originated:04-May-2008 09:47 PM
Status:Open Resolved:
Product:Mac OS X Product Version:10.5
Classification:Feature (new) Reproducible:N/A
04-May-2008 09:47 PM Pierre Lebeaupin:
Okay, this is going to be a bit special feature request; it’s not going to be a straightforward "could you make X do Y too" or "could you add function/method Z to API Q". Instead, what I’d like is for Mac OS X to have a modern, coherent, user-friendly system for dealing with file/document typing and application association, a Grand Unified Model for the 21st century if you wish. I know that’s a bit vague, and it’s not obvious how such a request would be fulfilled, so I’m going to expand a bit more.

Basically, the current model in Mac OS X is a mix of good old classic MacOS conventions (type and creator codes) which are seldom used anymore, and conventions inherited from NeXT such as reliance on filename extensions. Neither are appropriate today: classic MacOS convensions (much like the classic MacOS APIs themselves) were not meant for multi-user systems, moreover 4-char codes are limiting by today’s standards, and creator codes need to be registered; as for filename extension, it is not an appropriate file typing mechanism. Period. Just because everyone else uses it doesn’t mean it is good, and it suffers from so many limitations, has so many collisions, and breaks so many abstractions, that it would be ridiculous to list them all. As for interoperability (which is pretty much a necessity these days), it could be ensured by simply falling back to extensions if required, it doesn’t prevent the Mac from using a better model itself. Moreover the NeXT model basically assumes only one application can open a given type, which is poor for the user experience. Independantly of either model, the current way of dealing with users specifying an application to open a particular file (and not applying it to all files of this type) is not really satisfying as it creates a usro resource in the file, and sets as custom icon the icon the file would have if it indeed belonged to that application… this means creating a resource fork and Finder info if the file didn’t have one, makes it impossible for the user to do that on a file to which he doesn’t have write access, etc…

So I think it’s time for a brand new model that wouldn’t have the limitations of either model, one that would rely on UTIs, would make it possible for different users to have different preferred applications to open the same file, would rely on reverse-DNS, etc…

Now what should such a model be? I’m leaving it up to you. As long as it doesn’t have any of the shortcomings of the current Mac OS X model(s), I will be satisfied. However, I do have a few ideas on how it could be done.

To begin with, applications can currently make associations using UTIs and MIME types, but files can only be tagged with a type code or an extension, so it would be necessary to define an extended attribute to store the UTI of the file. It would not make sense to have this be on a per-user basis, since the file type is tightly related to the file contents which are the same for everyone. I think it would also be useful to define an extended attribute to store the MIME type of the file, which could be useful for files downloaded from the Internet (either through email or the web). If the file UTI is present, it would be used, otherwise the MIME type would be used if present, otherwise it would fall back to the current behavior.

Another extended attribute should be defined to store the "creator" of the file as a bundle identifier (creator which would not necessarily be an application); the "creator" would be defined as "the entity responsible for the file", typically the one that created it. This new creator would have pretty much the same semantics as the creator code (and would override it if it is present): it would be used by default to know which icon to give to the file, and if it would be an application it would be the one used by default to open the file (another entity, say a bundle/plug-in would perhaps have to define a message to be displayed if the user would attempt to open a file that would belong to it). This creator would NOT be on a per-user basis either, as the entity the file comes from is an intrisic property of the file, but it would be only used as a default for the purposes where it would play a role, and could be overriden by settings which would be on a per-user basis (more on that later). For files which don’t have any creator, they would be associated to the most suitable application that understands the type, as is done currently. Users would be allowed to override the type->application (i.e. which application opens a file on a file-type-wide basis) associations, possibly overriding the creator xattr/code, just like is done currently with the LS user prefs.

The user would also be able to override which application opens a file on a file-by-file basis (for instance most of my PDFs are things like books or references which are best opened with Adobe Reader, but I have some PDFs which are mere pictures which I prefer to open with Preview). Here the mechanism would depend on whether the user is the owner on the file. If the user is not the owner of the file, he may not have write access to the file, so the override would instead be recorded in the user preferences, with the file being stored as an inode number or some similar system (like an alias) that would allow the preference to follow the file to an extent if it is moved. If the user is the owner of the file, however, then the bundle identifier of the application would be stored in (yet) another xattr, different from the creator xattr. Contrary to the "not owner" case, this preference would be stored in the file metadata so as to follow the file whatever happens (since the user setting the pref is also the owner, he may transfer the file numerous times and expect the association to remain), for instance if it is moved from a work machine to an USB key to a home machine. A special case of these rules would be, if the user copies (using the Finder) a file which does not belong to him and if he has set an override for this file in particular (NOT in case of a file-type-wide override), since the copy belongs to him, then the override would be set as an xattr in the copy instead of a pref for this copy; that would allow the user to copy a shared file for which he has set a preferred application, and bring that copy elsewhere, and still have his override be respected.

As for the document icon, it should obviously come from the entity that would open the file, taking in consideration any override (thus removing the need to set a custom icon for a one-file override), if the entity provides one, so that the user may know at a glance "who" the file "belongs" to and would open it; if the entity doesn’t provide one, some fallback mechanism should be devised (to the creator, then the default entity for the type?).

A few points may be problematic. For instance, the introduction of QuickLook thumbnails makes things a bit more complex, since they often play the role of a document icon, should it be replaced by the document icon of the preferred opener, making the user lose the "smallish preview" feature if he sets a preferred opener that doesn’t provide a thumbnail? Also, the creator or in general the entity in charge (say, because it is the default for the type) may not be an application, but something similar to the CoreTypes bundle, however should users be able to override with an entity, and not just an application? It could be confusing, and it would probably be to fix a problem, so this would mean there is a flaw in the design, so the usefulness is debatable. And of course, there is the matter of interoperability; it’s not a problem for files coming from the outside to a Mac, since extensions would keep being recognised as a fallback, or better yet the application which downloads would set the UTI depending on the extension and/or the MIME type, but what to do for outgoing files isn’t clear: should applications continue to set an extension (on top of the UTI xattr) no matter what just in case the file would travel to the outside world eventually, or should the extension only be added when it exits? Since the exit is not necessarily controlled (for instance through an USB key), I’m (unfortunately) leaning towards the first solution.

Well, that ended up being pretty long. Tanks for bearing with me until the end. Good luck!

31-May-2008 10:46 PM Pierre Lebeaupin:
Oh, and just in case the absurdity of the current situation isn't clear enough, I give you this screenshot (attached file netlog.png). This file is typed as a simple text read-only doc, but QL tries to be overzealous and interprets whatever is after the dot as a file type, even though it's not a known extension and it's not actually an extension anyway. How could it know the text after the dot is not actually a file typing extension? That's my whole point, and the reason why extensions are inappropriate.

'netlog.png' was successfully uploaded

02-Oct-2009 01:06 AM Pierre Lebeaupin:
There are some remaining issues that I've realised recently, so I'll add the following suggestions to deal with them:

Some applications write files not intended for themselves, for instance in an exporting operation, or when they write files they can't read. In that case, the creator xattr should still be set, if only so that the system could tell what application it originated from (traceability), but a boolean piece of metadata should also be set to tell to ignore the creator information when figuring out what to open the file with, that way the file would naturally be opened by whatever handles files of this type.

If an application defines a document type with a custom UTI, but which conforms to a common one (like public.xml), and the document is transferred to a machine which does not have the application installed, the system on that machine won't know what to do with the document since nothing on the machine knows that the custom UTI conforms to public.xml. To solve this it should be possible to attach an imported declaration of the custom UTI in some xattr of the document file, for the system to use in determining what types it conforms to and what would best open it (for security reasons it would be used only for the file that has this declaration attached).

With icons generated by QuickLook it is no longer possible to tell in advance what is going to open the file, and it's making any mismatch between the user's expectation and the actual choice of application a pain, as the user then has to wait for the application to launch before quitting it, making him think he made a mistake. So I propose that applications be able to declare a badge (in a way similar as the way they declare an icon for the type) to be overlaid on the QL icon if that application is the one that is going to open the file. The aim is that, short of any very special case (like if the user set a custom icon for the file), it should always be possible tp predict what application is going to open the file only by looking at the file icon, or at least for the icon to provide a strong enough hint on this.

Obviously, it goes without saying that it should be as transparent as possible for applications to set this metadata on files they write, so that they adopt the behaviors as much as possible; it should be at worst opt-in flags for NSSavePanel for those behaviors that would break existing apps; apps should never need to explicitely manipulate the extended attributes themselves.


More wall of text

I added some more suggestions, both on Radar and here.

OpenRadar notes

There does not seem to be a way to attach files, so for netlog.png, imagine the screenshot of the icon, generated by QL, of a text file named " Log". Guess what is overlaid on the smallish text (or better yet, try it).

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!