Install Like It’s 1991
I thought this was pretty cool, too. The first time I saw it, over 10 years ago.
Not only that, but the old way (using creator codes) could take advantage of the file system’s catalog to do the search really fast.
4 Comments RSS · Twitter
In my experience, the launch services database is incomplete and often out of date. I'm not sure what the current rules are, but it used to be that it scanned certain locations on login and also recognized applications when they were launched. Creator codes are stored directly in the file system, so the database is always up to date. I could plug in an external drive and updaters would be able to find applications there, even if the drive had never previously been used on my machine. Maybe launch services can do that now through a brute force search, opening lots of XML files...
Namespace collisions were not inevitable because you had to register creator codes before releasing your app.
Yes, it's nice that you can reverse-engineer the identifier string, but really I think there should be separate metadata for identifying the creator of an application, and perhaps which "package" it's part of. Conflict Catcher had a nice system along these lines for System Folder stuff at one point.
Except that metadata stored directly in the filesystem breaks anytime you try to move the data through a filesystem that does not support said metadata...
... or try to use files mounted from a filesystem that doesn't store metadata.
I totally agree that the current system is not complete and has bugs. However, the old system-- while feature complete-- was a complete pain in the ass to deal with. It effectively made the mac a closed box. I know of many sites that simply refused to use Mac's because they didn't play well in a heterogenous environment.
It'd suck if OS X -- an otherwise totally open and well behaved system -- were to fall into that same quagmire.
I hear that argument a lot, so I guess other people had different needs or not the right tools. But, honestly, I've exchanged a lot of Mac files with Unix and Windows machines over the years and never had a problem. The file transfer software knew how to preserve some metadata and how to throw it away when it was unwanted. I've actually had a lot of trouble with OS X, though. Internet Config and filename extensions don't seem to work as well as before. That is, I get files that don't open or that open in a completely unsuitable application by default.
I'd like to see an improved system that eases interoperability without sacrificing the local (and Mac-to-Mac) experience. Right now, we're kind of in an in-between state.
I don't know what you mean when you say that OS X is "totally open."
So does the new way.... the identifiers are maintained in a database similar to the way creator codes used to be maintained.
Big difference: Creator codes are some stupid little four byte cryptic strings for which namespace collisions were inevitable. Identifiers are reverse fully qualified domains that are both human readable and imply an organizational hierarchy. Eventually, you should be able to say "Give me a list of all Apps Apple makes that are installed on my machine" simply by filtering for a 'com.apple' prefix on the identifiers.
Much better.
I totally agree that it is a bummer that Apple didn't get around to implementing this stuff until now. But, I would rather they take the time and do it right as opposed to perpetuating the stupidity...