IM Protokolle: eine Fehlentwicklung - warum SMTP besser gewesen wäre

Ich bin ja wirklich ein Freund von XMPP als Instant Message Protokoll. Und ich finde auch IM als Dienst mit all seinen Anwendung von Status Updates, über Chat bis Unified Messaging ganz toll.

Aber: dafür hätte man keine neuen Protokolle gebraucht. SMTP mit ein paar kleinen Erweiterungen hätte völlig ausgereicht. Messaging ist ja sozusagen die Kernkompetenz von SMTP. Dafür wäre sicher kein neues Protokoll nötig gewesen. Was sind Status Updates anderes als Messages? Chat: Messages mit einer Thread-ID. SMTP kann beliebige Content-types: text, HTML usw. Das hat HTTP schließlich von SMTP gelernt. Wie wir alle wissen kann SMTP sogar multipart messages (MIME). Das muss ein IM Protokoll erst mühsam nachmachen.

Um hier mal mit Mythen und Halbwahrheiten aufzuräumen:

IM ist schneller als Email

EMail ist nur deshalb langsam weil mein Email-Reader nur alle 5 Minuten die Email abholt. Würde er seine TCP Verbindung zum Mailserver stehen lassen, dann könnte der Server immer sofort die Email an den Client weiterleiten. Sozusagen COMET für SMTP. Wenn es bei HTTP geht, dem Prototyp eines Request/Response-Protokolls, dann geht es auch bei SMTP. Noch besser: jeder sollte einen SMTP Server im Email-Client haben und der Company-Server forwarded einfach live an den Client. SMTP Messages gehen meistens 3 Hops: Sender -> lokaler Server -> entfernter Server -> Empfänger. Das ist genau die gleiche Topologie wie bei XMPP.

IM ist SPAM-resistenter als Email

Nur manche IM Systeme sind SPAM-resistenter und zwar deshalb, weil das Gesamtsystem in einer Hand ist. z.B. können bei zentraler Registrierung Accounts gebannt werden. Oder weil sie Dialback und Sender-Authentifizierung machen. Das ist aber nicht das Protokoll, sondern das Gesamtsystem. Ein Emailsystem mit Sender-Auth, Dialback und Benutzern, die nicht alles glauben ist genauso gut oder schlecht SPAM-resistent wie IM.

Mit SMTP kann man nur Emails verschicken

SMTP kapselt alles was man will. Alle MIME-Typen (MIME! klingelts?), vor allem auch XML. Auf XML sind ja ein paar IM Protokolle mächtig stolz. Mit beliebigem XML in SMTP lassen sich auch beliebige Daten übertragen. Es gibt sogar einen SMTP Network-Layer in .NET zum Transport von SOAP-XML als Remote Procedure Call. Natürlich hätte man auch ein bisschen Status-XML übertragen können. Oder Subscriptions, Notifications, Requests, Responses, und alles was man sich nur wünschen kann.

Warum SMTP besser ist (gewesen wäre)

SMTP ist hochentwickelt im Vergleich zu IM Protokollen. Und das sogar immer noch obwohl IM nun schon über 10 Jahre alt ist.

SMTP ist einheitlich während die IM-Welt zersplittert ist.

SMTP hat Offline Storage eingebaut. Manche IM Protokolle mussten das erst wieder erfinden.

Die SMTP Infrastruktur war schon weltweit operativ, robust und verstanden. Es wäre nicht notwendig gewesen neue Software zu machen, zu betreiben, kennen zu lernen.

Meine IMs würden automatisch archiviert, wie Emails. Es gäbe da keinen Unterschied. GMail hat das gerade wieder erfunden.

Es gibt Web-basierte Email-Reader, sehr praktisch im Urlaub. Auch das haben die IMs wieder erfunden (z.B. Meebo), aber warum ist das überhaupt separat. Ach ja, GMail hat GTalk mit eingebaut. Schade, dass sie überhaupt was einbauen mussten.

Was notwendig gewesen wäre

Um SMTP noch ein bisschen leichter zu machen hätte man z.B. SMTP Pipelining verwenden können. Pipelining befreit SMTP von den 4 Round-Trips. Nicht dass es wirklich wichtig wäre.

Eine Art SMTP-COMET oder einfach ein SMTP-Server für Jedermann.

Jetzt mal ehrlich...

...meine Kommunikationsanwendung ist Thunderbird oder Outlook. Die Buddyliste gehört in Thunderbird. Sie sollte identisch mit dem Adressbuch sein. Ein Adressbuch mit Online-Status. Und kurze Email heißen dann IM.

Trotzdem gibt es XMPP und andere IM Protokolle. Und dabei wird es auch bleiben. Lesen Sie auch bald wieder hier: "RSS-Feeds: eine Fehlentwicklung - warum XMPP besser gewesen wäre".

Wer braucht XSL?

Habe ich jemals über meine Abneigung gegenüber XSL geschrieben? 2 Kritikpunkte: 1. Lesbarkeit, 2. Trennung von Code und Design. Wegen Punkt 2 finde ich XSL schlecht und falsch. Wegen Punkt 1 hasse ich es. Kurz: 1. XSL ist unleserlich. Die Skriptbefehle sehen genauso aus, wie die Daten und sind dazwischen verstreut. 2. Der Skriptcode im gleichen Dokument, wie das Design. Beides vermengt bildet das XSL. Früher hat man mal Code und Design getrennt.

Zu 1: XSL kommt heraus, wenn ein XML-Liebhaber eine Skriptsprache erfinden will und deshalb alle Sprachelemente in spitze Klammern packt.

Muss eine foreach Schleife wirklich so aussehen:

<?xml:namespace prefix = xsl /></xsl:for-each>

Das sah auch schon mal in anderen Sprachen so aus:

foreach (item in dom.xpath("/sales/record")) ;

Glaubten die XSL Erfinder wirklich, dass man nur XML ganz toll parsen kann und deshalb muss man eine Skriptsprachen im XML Format machen? Dazu kommt noch, dass die meisten Leute mit XSL am Ende dann HTML/XHTML erzeugen. Die HTML Fragmente stehen zwischen den XSL Tags und alles sieht nach Spitze-Klammer-Doppelpunkt-Slash Einheitsbrei aus.

Zu 2: Wo wir schon gerade bei der Mischung von XSL-Skript und HTML sind. Die XSL-Skriptanweisungen sind Code. HTML mit CSS ist das Design. Gerade, weil man bei HTML ja gerne mal Formatierung mit Tabellen macht. Also sind bei XSL Code und Design vermischt. Eine tolle Idee. Wer hat schon mal von Templates gehört? Ein Template, das ist ein Dokument, dass ein Design festlegt. Es enthält keinen Code, außer vielleicht Javascript Code für die Clientseite. Code sollte ein Template benutzen, nicht im Template drin stehen.

Das richtige Design wäre gewesen: Eine Skriptsprache, die aus Daten und einem Template schließlich HTML erzeugt. 3 Dateien: Skript(Code), Daten(XML oder Datenbank), Design(Template). XSL verwendet typischerweise nur 2 Dateien: Daten(XML), Code und Design(XSL). Schade.

Skriptsprachen gibt es genügend. Die hätte man nicht erfinden müssen. Im Fall von XSL hätte sich das Javascript angeboten, weil das sowieso schon im Browser implementiert ist und auch in vielen Application-Servern. Oder vielleicht PHP oder Python oder man hätte das variabel gelassen und nur eine einheitliche Templateschnittstelle geschaffen.

Warum rege ich mich überhaupt auf? Wir trennen Skriptsprache und Template bei allen Projekten. Was schert uns was die anderen machen? Es gibt eben Leute, die großen Einfluss auf die technische Entwicklung haben, weil sie in einem Moment an der richtigen Stelle sitzen und alle zu ihnen aufschauen. Eine solche Stelle ist(war) das W3C (WWW Consortium), dass die Web Standards macht(e). Wenn solche Leute falsche technische Entscheidungen treffen, dann haben sie eine Chance, dass es trotzdem die ganze Welt nachmacht. Auf diese Weise ist XSL zum Standard geworden und sogar in Browser eingebaut worden. Das wäre einfacher und besser gegangen. Schade dass keine 3-komponentige Formatierungsengine in Browser eingebaut wurde. Die könnte man gut verwenden.

Bei der Gelegenheit möchte ich auch noch mal anmerken, dass Leute, die HTML und PHP mischen, keinen Deut besser sind, als XSL-ler.

Etwas ausführlicher und auch schon etwas früher steht das auch hier, aber ich habe es erst heute entdeckt und musste das mal loswerden.

_happy_coding_

SAX sucks

Eine Kritik am SAX Interface

Neulich auf der Jabber Developer Liste: Ein Noob-Developer beschwert sich, dass er das Jabber Protokoll nicht verarbeiten kann, weil das letzte Tag nicht kommt. (Zur Erklärung ein paar Vokabeln: Noob = Newbie (engl.) = Neuling, Jabber = XML-basiertes Instant Mesage Protokoll, das letzte Tag = das schliessende XML-Tag eines XML-Dokuments). Neben den üblichen mailinglistentypischen dümmlichen Antworten, erhält er die wertvolle Empfehlung, einen SAX Parser statt dem DOM Parser zu verwenden. Das ist richtig, denn im Jabber Protokoll wird ein XML-Strom verarbeitet. Der gesamte Strom ist ein einziges Dokument und da dieses nie fertig ist, geht es nicht mit einem DOM Parser. Danach war einen Tag Ruhe, dann kam die nächste Frage etwa so: "Der SAX Parser meldet zu viel und das falsche. Der SAX Parser ist nicht brauchbar. Was nun?"

Da hat er leider Recht. Der SAX Parser meldet nämlich Öffnen und Schliessen jedes XML-Tags und jedes Fitzelchen Daten zwischen den Tags, selbst wenn das nur ein Zeilenumbruch ist. Damit kann der Applikationsentwickler aber leider nichts anfangen. Eine Jabber Message sieht als XML so aus:

<message from='cs@bluehands.de' to='hw@bluehands.de'>
<body>Hallo Welt!</body>
</message>

Der SAX Parser liefert dafür eine Serie von Callbacks:

startElement "message"
characterData "\n "
startElement "body"
characterData "Hallo Welt!"
endElement "body"
characterData "\n"
endElement "message"

Was soll man jetzt damit anfangen? Klar, der Anwendungsprogrammierer muss alle Teilinformationen sammeln bis das Ende der Message signalisiert wird. Dann kann er die gesamte Message auswerten. Anders ausgedrückt: XML hat eine hierarchische Struktur. SAX serialisiert und unterdrückt die Struktur. Der Anwendungsprogrammierer muss die Struktur wieder rekonstruieren. Eine Aufgabe, die in eine Bibliothek gehört. Leider ist sie bei SAX Parsern nicht enthalten. Nu ist an SAX Parsern nichts falsch, denn SAX heisst "Simple API for XML". Man wundert sich nur, warum es nach vielen Jahren XML immer noch keine besseren Schnittstellen für XML-Streaming gibt.

Was man eigentlich will ist eine Mischung aus DOM und SAX. Für die Verarbeitung von XML-basierten Protokollen braucht man einen Parser, der wie eine SAX Parser XML-Fragmente verarbeitet, der dann aber jedes komplette XML-Tag als Struktur liefert, so dass man nicht selbst die Struktur rekonstruieren muss. Also eine Art "Fragment API for XML". Wenn jemand fragt, wie man das Jabber Protokoll verarbeitet, heisst die richtige Antwort: nimm einen FAX Parser, z.B. meinen.

_happy_coding_