(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

CMS gibt es ja nun wirklich wie Sand am Meer. Warum also hab ich mir hier was eigenes gebastelt?
Ich gebe zu, es sieht stark nach NIH-Syndrom aus. Hauptsächlich liegt es daran, daß ich die Fähigkeiten eines komplexen CMS schlicht nicht brauch(t)e. Zu Beginn habe ich mit statischen Seiten gearbeitet. Um alle paar Wochen oder gar Monate mal eine Änderung zu machen, lohnt sich ein datenbankgestütztes System nicht.
Das änderte sich, als ich den Nutzern meiner Quelltexte (siehe Cocoa-Seite) eine Möglichkeit bieten wollte, Erfahrungen auszutauschen und öffentlich Fragen zu stellen. Ein Kommentarsystem mußte her.
Zwar hätte ich auch eine Forensoftware benutzen können; leider habe ich damit schon eher weniger gute Erfahrungen gemacht. Alles was ich mir angesehen habe, ist mit (mehr oder weniger nutzlosen) Features vollkommen überladen: Avatare, internes Mailsystem, Ränge, Statistiken, BBCode, etc. pp.
Alles wegzukonfigurieren bzw. im Quelltext zu entfernen, was ich nicht brauche, schien mir mehr Aufwand, als selbst ein einfaches Kommentarsystem zu schreiben.
Das war dann auch kein großes Problem und funktionierte eine ganze Zeit lang zufriedenstellend.
Ein Nachteil des Systems war, daß ich — da ich ja jeweils einen Einstiegspunkt für die Kommentare brauchte — neue Themen doppelt anlegen mußte. Einmal für das Kommentarsystem, einmal auf der statischen Seite.
Letztens wurde mir das dann (zumindest für die News-Einträge) zu dumm und ich habe aus der statischen eine dynamische Seite gemacht, die die Einträge aus der Themenliste des Kommentarsystems liest.
Noch während ich das realisiert habe, wünschte ich mir zu mehreren Gelegenheiten, ich hätte einen Platz, um mal schnell meinen Gedanken zu etwas veröffentlichen zu können, so daß ich später wieder darauf verweisen kann. Ihr kennt das sicher: Man führt irgendwo — zum Beispiel in einem Forum — eine Diskussion, formuliert eine ausführliche Stellungnahme zu einem Thema, nur damit das dann im allgemeinen Traffic der betreffenden Seite untergeht. Und bei nächster Gelegenheit, wenn das Thema mal wieder zur Sprache kommt, wünscht man sich, man würde den Beitrag von damals wiederfinden ...
Nun, technisch hatte ich ja bereits eine solche Seite. Nur war die halt thematisch bereits festgelegt. Es bot sich also an, mit dem gleichen System im Hintergrund eine weitere Seite zu bauen, die für andere Themen zur Verfügung stünde.
Im Verlauf der Arbeit daran, stellte sich dann noch eine neue Anforderung heraus.
Auf den Cocoa-Seiten schreibe ich ja in Englisch; weil das die Sprache ist, die der größte Teil der Zielgruppe spricht. Aber wenn es nicht grade ums Programmieren geht, ist es natürlich oft sinnvoller, Beiträge in Deutsch zu verfassen. Nicht nur, weil ich das besser beherrsche ... ;-)
Tatsächlich habe ich das System jetzt so erweitert, daß ich Beiträge zweisprachig verfassen kann. Oben rechts auf der Seite kann der geneigte Leser wählen, welche Sprache er sehen möchte. Das wirkt sich dann nicht nur auf das Interface aus, sondern auch auf die Beiträge: Solche, die ich in beiden Sprachen verfaßt habe, werden in der gewählten angezeigt. Andere, die nur entweder auf Deutsch oder Englisch vorliegen, werden angezeigt wie sie sind.
Die Kommentare zu einem Beitrag werden übrigens immer alle zusammen angezeigt, unabhängig von der Sprache, in der sie verfaßt wurden. Das heißt, die englischsprachigen Leser bekommen auch die deutschen Kommentare zu sehen und umgekehrt. Das ist Absicht so; ich hoffe damit ein ganz klein wenig zur Kommunikation zwischen den beiden Gruppen beizutragen.

Nun muß ich nur irgendwann noch was interessantes hier schreiben. ;)

In diesem Sinne: Jetzt und in Zukunft noch viel Spaß hier auf harmless.log!