Creator Codes and UTIs

Is Snow Leopard actually Windows Vista?

I've owned Macs for more than two decades, and this is the first upgrade I'm thinking of just sitting out.

It's already the first upgrade I haven't done in the first two weeks of release...

-----

I mean, seriously, other than AppleScriptObjC and the cool new services infrastructure, what's the point for the end user?

No new features. No new speed. And it breaks far more things than it has bug fixes.

To be alarmist, is this the first sign that desktop OS X is being EOL'ed? Or was it just that Steve-O was sick?

A very dramatic and concise summary but it leaves out an important fact. Creator codes are a bit cumbersome as they impose the requirement that files contain Apple specific meta-data (anyone remember the old resource forks in the pre OS X era). When you move this file between OS you loose the creator code anyway.

My main point is this: We don't need no stinkin' creator codes!!! :) There is already functionality in Mac OS X that stores file metadata in a cache, it is called Spotlight, and it would not be very difficult to store some kind of application affinity (creator codes) in that database. There are very few files on a users disk that need application affinity, beyond file endings, to begin with (a user most certainly does not want to have different creator codes preferences for thousands of files, probably a couple of dozens at most in real life situations.

Best regards,
Stefan

Stefan: I think that fact is hardly important. It really doesn’t matter to me that creator codes might be lost when transferring files to a different OS. At least they allow for a better local experience without introducing any problems. It’s obviously going to be Apple-specific metadata, anyway, since all of my preferred applications are Mac-only. If you read Gruber’s full article you’ll see that Apple’s “replacement” for creator codes is actually resource forks!

The fact that Spotlight is a cache is exactly the reason it wouldn’t work for what you’re suggesting. You cannot cache what isn’t already stored somewhere. Extended attributes are a cross-platform technology that are much better suited for this.

If it only boils down to "a better local experience without introducing any problems" then you have reduced it to a technical problem that lies outside the realm of the user. The user doesn't care where the data is stored only that the system behaves in specific way. The technical problem being where to store the "creator code". Steering away from theoretical issues such as normalization of data (not very nice to add a data element to the file that is almost completely orthonormal to data content of the file) let's just say that where the creator code is stored is not important (if in fact you are earnest when you maintain that this is just about the local experience).

"You cannot cache what isn’t already stored somewhere. "

Everything in this world is transient anyway so you can, if you feel better, just assume that the Spotlight cache is a long term cache bordering on a permanent database, which is not too far from the truth :)

Anyway whichever method you choose you need to manually create the connection between the application and the file at some point. Just as when a new file is added to a Mac OS X filesystem the Spotlight subsystem is notified and the file is added to the "cache".

I consider creator codes to be a transient or volatile attributes of a file and therefore I feel that they should not be part of the file itself.

Apple has not irreversibly eliminated the functionality of creator codes as the original article implies. I have just described a simple way how to restore this functionality using the Spotlight cache.

I care about how the system behaves, not where the information is stored. However, the Spotlight database is much more fragile and transient than creator codes. To pick just one example, it doesn’t even survive a Time Machine restore. Apple had a working implementation, which they apparently turned off because they didn’t like the behavior. You seem to be OK with the behavior, but you want a new implementation that, so far as I understand, doesn’t improve on any aspects of the old implementation, except perhaps aesthetically. And it’s something that Apple would have to do, not a third party—just like the article says.