(Ursprünglich geschrieben als Kommentar auf heise.de zu „Diskussion über Springers Bezahlinhalte“.)

Die Journalisten werden es nicht müde, zu betonen, daß die Menschen ja auch in der Vergangenheit gerne für guten Journalismus bezahlt haben.

Aber stimmt das überhaupt?

Ich behaupte, das ist nicht der Fall. Der Leser hat in der Vergangenheit für die Zeitung bezahlt. Und meinte damit das physische Produkt; das Papier, auf dem die Artikel gedruckt waren.
Es gab ja auch schlicht keine andere effiziente Möglichkeit, zu aktuellen Nachrichten in geschriebenem Wort zu gelangen. Irgendwer mußte sie auf Papier drucken und verteilen. Und genau das haben die Verlage gemacht. Sie haben die Nachrichten gesammelt, aufbereitet und dann auf Papier gedruckt und verteilt. Für all diese Leistungen zusammen haben sie einen Pauschalpreis verlangt.
Somit hat gewissermaßen der Zeitungsdruck den eigentlichen Journalismus mitfinanziert.

Schnitt. Heute gibt es das Internet. Das Verteilen des geschriebenen Wortes ist jedermann nahezu kostenlos möglich. Bedrucktes Papier entwickelt sich zum Anachronismus.

Nachdem die Menschen früher genau dieses bedruckte Papier bezahlt und die Nachrichten an sich kostenlos dazu bekommen haben, verhalten sie sich heute genau so, wie sie es schon immer getan haben: sie konsumieren das geschriebene Wort zu Pauschalpreisen (DSL-Verbindung) und erwarten, daß die Inhalte einfach dazu gehören.

Mit anderen Worten: Das alte Geschäftsmodell - Nachrichten sammeln, auf Papier vervielfältigen und das Papier verkaufen - funktioniert nicht mehr.

Und ein neues ist nicht in Sicht.

Ich bin gespannt, wie der Versuch, das bedruckte Papier mittels Bezahlbarrieren zu simulieren, verläuft. Aber ich gebe dem keine großen Chancen. Zu einfach ist es, die eigentliche Information weiterzuverteilen.

Und natürlich stellt sich zudem die Frage, ob solche Barrieren überhaupt sinnvoll sind. Eigentlich sollten wir uns doch darüber freuen, daß es so einfach und kostengünstig geworden ist, Informationen zu verteilen.

OK, so I'm late to the party.

Apparently, Apple removed support for Mac creator codes from Snow Leopard. What has gone unnoticed by almost all users seems to create quite a bit of rouse in blogs in the last few days. While I'm relatively impartial as to the importance of creator codes, there has been some misinformation that I think needs to be cleaned up. The (correct) answers are out there by now, but it's mostly just in comments to other posts. I'd like to change that.

The post that made me aware of the discussion was by Daniel Eran Dilger from RoughlyDrafted Magazine:

http://www.roughlydrafted.com/2009/09/22/inside-snow-leopards-uti-apple-fixes-the-creator-code/

I am a bit of a fan of Daniel's elaborate and entertaining analyses of all things Apple. The article mentioned above though lacks accuracy and I feel the need to correct a few things.

First — this is not really that important, just to get it out of the way — type codes do not just go from 0000 to ZZZZ. While they are usually represented using four characters, they are actually defined as unsigned long. That means a type (or creator) code may consist of four arbitrary bytes. So instead of 456976 (26^4), there are 4294967296 (256^4) possible values for a type code.

OK, now let's discuss UTIs.

What is a UTI?

Well, to answer that, it's best to first understand, what it is not.

What a UTI is not

• A UTI is not a new kind of meta data.
• The UTI for a file is not saved anywhere along with the file.
• A UTI is a derived value.
• This means there is no way to change the UTI for a file without changing something else about the file.

But you can get the UTI of a file, so the information must be saved somewhere, you say.

Of course. As stated above, the UTI is a derived value. The OS may look at different types of metadata to infer its type. At the moment it uses a) the Mac type code b) the file extension and possibly c) the MIME type. (The order of relevance is up to the system and did actually change in between OS releases, IIRC.)

So, to change a file's UTI you have to change either its type code or its file extension – whatever is actually there and the system looks first at.

Why the UTI can not replace the Creator Code

This is not as clear-cut as it seems.

To emulate a creator code, Daniel suggested applications could use private UTIs.

We now learned that this would require a different file extension. This, at first, seems to break interoperability with other applications but it would actually work, since UTIs – again, like Daniel pointed out – are hierarchically organised. For instance TextEdit would be able to recognize a file from my-proprietary-editor with a "my-proprietary-txt" extension as text as long as the UTI is correctly defined.

The problem is: This definition is located inside the application bundle of the my-proprietary-editor app.
Now copy this file to a machine without my-proprietary-editor installed, and the system will have no clue what to do with this strange my-proprietary-txt file.

Creator codes were stored separately from the type code, so that has not been a problem there. (Unless, of course, you'd copy the file to a machine that does not support type or creator codes at all, like anything not-Mac …)

Conclusion: Unless you expect everyone to use your favourite editor, UTIs are not suited to replace creator codes. Even in a Mac-only environment.

So what are UTIs good for anyway?

UTIs are a system facility to provide a unified API for accessing type information about data.

Yes, it's really as generic as it sounds.

Using UTIs the programmer does not have to worry any more if the file has an extension of 'JPG', 'jpeg' or no extension at all and a type code of 'JPEG' instead. Or it may even be an email attachment with MIME type 'image/jpeg'.

Even better, if you just want to know if the file is any kind of image you can test if its UTI conforms to 'public.image'. Done. This will cover any file extension, any Mac file type and any MIME type that the OS knows is used for some kind of image format.

So UTIs are very useful — for programmers. They have almost no relevance for users.

Now, what about creator codes?

They are completely ignored by the OS.

There is no replacement.

You may still set a preferred application for each individual document, but this is a purely local setting for a user. It can't be set by an application and it will not travel with the document.

I'll leave it to others to argue if this is a good or a bad thing.

The Mac OS X Reference Library about UTIs

There are more CMSs than you can shake a stick at. So why did I build my own here?
OK, so it does look a lot like NIH syndrome. The main reason might have been, that I just didn't need a complex CMS. In the beginning I just used static pages. To only make a change every few weeks or even months, you really don't need a database backed system.
This did change when I wanted to give the users of my Cocoa sources (see the Cocoa pages) a place to share their experience and publicly ask questions. I needed a comment system.
While I could have used some online forum software, I had made experiences with those packages, that were — well — rather not that good. Most forum software that I came across has an abundance of (more or less useless) features: avatars, internal mail boxes, user rankings, statistics etc.
To switch everything off that I didn't need or remove it from the source would probably take more time, than to write something on my own, I thought.
So I went ahead and build my own; and it did work to my satisfaction for some time.
One downside of my system was that I had to create all new topics twice — once as an anchor for the new comment system and once on my static pages.
I finally had enough of this and replaced the static page with a dynamic one that would retrieve it's entries from the comments system. (At least the for the Cocoa news.)
Around the same time I was working on that, I realized that I would really like to have some space to publish my thoughts on diverse topics, so that I could link to them when the need arises. I guess this happens to all of us: You have an online discussion — say in a forum or such — take a lot of time to formulate an articulate response ... just so that it get's lost in the particular site's traffic. And when the same topic comes up somewhere else, you wish you could find that particular post from before ...
Well, technically I already had that space. Only that it was reserved for one particular topic. The obvious solution seemed to be to create a new page based on the same system, that would be open for other topics.
While I was building that page, I realized that I needed one additional feature.
Even though I am German, I'm writing my Cocoa topics in English. Simply because that's the language most of the target audience understands. But when I'm not writing about programming topics, I'd rather use my native tongue. And not only because I'm better at it. ;-)
In the end I did enhance my system in a way so that I can write any article in both languages. Visitors can change their language preference on the upper right of the page. This will not only affect the page's user interface but the articles too: Those that I wrote in both languages will show up in the one selected by the reader. Those that only exist in English or German will show up in whichever language they were wrote in.
Incidentally, all comments for a topic will show up together. No matter if the writer commented on the English or the German version. That's my bit of contribution to mutual understanding.

OK, so all that is left is for me to post something interesting. ;)

In this spirit, I hope you will have fun on harmless.log!