Bitte ein Bit, oder: Warum XML die richtige Wahl für XMPP war

XML ist eine „menschenlesbare“ Auszeichnungssprache, also nicht nur kryptisch codierter Code (okay, natürlich ist XML „unten rum“ auch nur Binärcode, aber dazwischen ist eben eine Präsentationsschicht). Dies bringt jedoch den Nachteil mit sich, dass Menschen zum Lesen nicht irgendwelche Register haben, wo sie möglichst kurze Variablen ablegen können, um später jederzeit darauf zuzugreifen. Ein „“ hat bereits neun Zeichen – ein Rechner bräuchte diesen Overhead nicht. Für uns als Menschen ist es jedoch ein doch recht aussagekräftiges Element. Aber z.B. beim Chatten sieht man den XML-Schnipsel ja eigentlich nicht (Freaks mal ausgenommen *pfeift unauffällig*), sondern nur den Inhalt der Nachricht, aufbereitet in einem schönen XMPP-Chat-Programm. Unter der Haube könnten da doch ruhig Bytes gespart werden – schließlich bedeutet Chatten im Normalfall, dass die Nachricht in das Internet über mindestens einen Server, zahllose Router bis zum Empfänger der Nachricht – welcher auch gerne auch mal auf der anderen Seite unseres Planeten sein kann – gejagt wird. Wäre es gerade da nicht gut, großen Wert auf kompakte Paketgrößen zu legen? Ich denke, mir werden nicht viele widersprechen, wenn ich sage, dass diese Frage eher rhetorischer Natur ist (Für den Rest: „Ja!“).

Nun, warum wurde also beim Design der Sprache eine solch verschwenderische Sprache wie XML gewählt? Da XMPP ja aus guten Gründen auf Unicode (UTF-8) aufbaut, bedeuten die zusätzlichen Zeichen einen nicht insignifikanten Anstieg der benötigten Bits. Ist also auf den falschen Unterbau gesetzt? Ich für meinen Teil verneine dies.

Als 2004 XMPP zu einem offiziellen Standard wurde, war die Intention natürlich, dass sich dieses Protokoll schnell und weit verbreiten wird. Wäre anstatt XML eine z.B. rein binäre Kodierung gewählt worden, hätte dies vermutlich in der Zwischenzeit viel Bandbreite gespart. Zum Einen, weil es kompakter gewesen wäre. Zum anderen, weil XMPP/Jabber wohl kaum benutzt werden worden. Das schöne an XML, die Lesbarkeit, macht das Entwickeln und die Fehlersuche erheblich einfacher. Wer programmieren kann, hat mit XML auf jeden Fall keine Probleme, die Lernkurve ist extrem steil (== viel Lernen in kurzer Zeit ;-)). Wenn man sich erst einmal zwei Monate mit der Art und Weise der Kodierung auseinander setzen hätte müssen, hätten wir heute wohl kaum ein so gesundes Ökosystem an Software, die XMPP nutzt. Von daher ist XML meines Erachtens ein guter Ausgangspunkt für weitere Entwicklungen – und es hat sich ja bewährt.

Ein weiterer Pluspunkt bezüglich XML ist die einfache Erweiterbarkeit. Auf jene bin ich mehr oder minder ja hier bereits eingegangen. XML ist einfach per Definition gut zu erweitern. Ob das bei einem Binärprotokoll so elegant geklappt hätte, wage ich zu bezweifeln.
Somit wäre das Projekt Jabber und erst Recht XMPP (oder wie auch immer es ohne das X, welches es vom XML geerbt hat geheißen hätte) vermutlich recht schnell im Sand verlaufen. Die Menschen lieben eben auch in der digitalen Welt Dinge, die man „greifen“ kann.

Ja, aaaaaber trotzdem ist XMPP ja sehr „Bithungrig“. Ja, das stimmt schon. Und auch zu Zeiten von breiten Datenautobahnen sollte man sich überlegen, ob man die Daten nicht kompakter übermitteln kann. Schließlich ist auch das mobile Internet nicht überall gut ausgebaut. Auch bei XMPP wurde darüber nachgedacht, es gibt eine Erweiterung (XEP-0138: Stream Compression), die beim Verbindungsaufbau zwischen zwei Entitäten versucht, einen Kompressionsalgorithmus auszuhandeln. Somit werden die übertragenen XML-Schnipsel aka Stanzas in verkleinerter Form übertragen, wenn Server und Client sich darauf verständigt haben. Somit sollte das Datenaufkommen doch stark reduziert sein.

Und wer generell etwas gegen XML hat, mag wohl auch kein HTML und das, was daraus geworden ist, oder? Gut, da kann ich dann nichts gegen sagen. Klar wäre auch hier vielleicht eine kleinere Auszeichnungssprache möglich gewesen (ich bin mir immer noch nicht sicher, ob z.B. JSON wirklich so viel Einsparungspotential gehabt hätte), aber der Erfolg zeigt doch relativ deutlich, dass man mit XML nicht auf das falscheste Pferd gesetzt hat 😉 Und wenn sich eine Sprache fände, die so elementare Vorteile bringen würde – was spräche dagegen, eine XEP zu formulieren, in der die Translation zwischen jener Sprache und dem normalen XMPP geregelt und ausgehandelt werden würde? Klar, das wäre dann je nach Implementierung ein Tick mehr Rechenarbeit, aber würde wohl kaum dramatische Ausmaße annehmen. Es ist eben eine „eXtensible Markup Language“ 🙂

So, alles in Allem bin ich jedenfalls für mich zu dem Schluss gekommen, dass XML eine sehr gute Wahl gewesen ist – auf eine Bessere wäre ich jedenfalls nicht gekommen.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*