Last-Crusade.de – The Empire Writes Black Stories of these dark and modern days…

16Mai/113

Schon gewusst?

Schon gewusst, dass bei Straßenbegrenzungspfosten (aka Pinguine...diese weißen Pfosten mit Schwarzen greifen am Straßenrand eben) immer dann einen gelben Reflektor haben, wenn sie um eine Einfahrt, also z.B. ein Feldweg, der in die Straße mündet, stehen?

veröffentlicht unter: Allgemein, Schon gewusst? 3 Kommentare
16Mai/110

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.

veröffentlicht unter: Jabber/XMPP keine Kommentare
9Mai/110

Schon gewusst?

Schon gewusst, dass die Mobiltelefon-Eingabemethode T9 eine Abkürzung für Text on 9 keys ist?

veröffentlicht unter: Allgemein, Schon gewusst? keine Kommentare
5Mai/111

XEP-049 (Private XML Storage): Die Möglichkeiten

Ich bin ja immer wieder von den Möglichkeiten von XMPP positiv überrascht. Was mir gerade klar wurde, ist die simple, aber geniale, Funktionsweise von XEP-0049 (Private XML Storage). Es bietet schlicht und ergreifend einen neuen XML-Namespace xmlns="jabber:iq:private"

In diesem kann dann an Kind-Elementen stehen, was will. Wozu das Ganze? Wieso sollte ich Daten auf meinem Jabber-Server speichern? Nun, im Folgenden mal die drei Beispiele, die ich in Implementierungen gefunden habe.

  1. Storage Notes
    Hierbei handelt es sich schlicht und ergreifend um die Möglichkeit, sich Notizen anzulegen. Jeder Notiz kann über einen Titel, Tags und eben den Inhalt verfügen. Ein Implementierungsbeispiel findet sich auf diesem Bildschirmfoto im Psi+-Wiki: klick. Um die Notizen einzusehen, wird ein InfoQuery-Stanza (Stanza, so heißen die XML-Schnipsel von XMPP) in dieser Art verwendet: 

    <iq type="get" id="23">
    <query xmlns="jabber:iq:private">
    <storage xmlns="http://miranda-im.org/storage#notes" />
    </query>
    </iq>

    Was auffällt, ist das Kindelement <storage>, welches den Namespace "http://miranda-im.org/storage#notes" zugewiesen bekommen hat. Dies führt zu der Vermutung, dass Miranda IM dieses Feature erfunden hat. Als Resultat wird man hier eine Liste mit den verschiedenen Notizen bekommen, was in etwa so aussehen kann:

    <iq from="bob@example.com" type="result" to="bob@example.com/home">
    <query xmlns="jabber:iq:private">
    <storage xmlns="http://miranda-im.org/storage#notes">
    <note tags="Jabber XMPP">
    <title>Private XML Storage</title>
    <text>Informationen suchen und Blogeintrag schreiben</text>
    </note>
    </storage>
    </query>
    </iq>

    Unschwer die Notiz zu erkennen.  In diesem Beispiel war eben nur eine Notiz vorhanden.

    Ich für meinen Teil finde die Funktion sehr praktisch. Bisher vorgefunden habe ich sie außer in Miranda und Psi+ noch nirgends.

  2. MUC-Bookmarks
    Die Funktion, Multi User Chatrooms zu speichern und überall verfügbar zu haben, wird in XEP-0048: (Bookmarks) definiert. Hier sieht der der Storage-Tag samt dazugehörigem Namespace so aus: 

    <storage xmlns='storage:bookmarks'>

    Elegant und praktisch!

  3. Kommentare zu Nutzern im Roster (Kontaktliste)
    Ein nettes Features, welches ich in Vacuum IM vorfand,  ist die Möglichkeit, sich zu jedem Kontakt eine Notiz hinzu zu fügen (z.B. Erinnerungen oder wer die Person eigentlich ist...). Bei Vacuum IM werden diese in der Info-Box beim überfahren des Kontaktes eingeblendet.
    In dem Kommentar wird darüber hinaus noch das Erstellungs- und das letzte Änderungsdatum gespeichert. 

    <iq type="set" id="42">
    <query xmlns="jabber:iq:private">
    <storage xmlns="storage:rosternotes">
    <note mdate="2011-05-04T22:46:17Z" cdate="2011-05-04T22:46:17Z" jid="update@identi.ca">Alle neuen Beiträge auf Identi.ca</note>
    </storage>
    </query>
    </iq>

    Nachtrag: Die Rosternotes haben sogar eine XEP: XEP-0145 (Annotations). Interessanter Weise habe ich bei meiner Suche eine neue Version 1.1 (klick) der XEP gefunden, die das Gleiche via Pub-Sub macht. Dann würde obiges natürlich obsolet werden - aber seit Ende 2007 hat sich da nichts mehr getan, wird also für's Erste bei der jabber:iq:private-Variante bleiben.
    Nachtrag 2, 03.08.2011: Ich habe festgestellt, dass Gajim in den Details des Nutzers einen extra Reiter hat, in dem die Roster Notes gezeigt und bearbeitet werden können. Das Ding (Gajim) kann echt viel, das muss man ihm lassen.

 

Das sind also die drei Anwendungen, die mir in der Praxis begegnet sind - und ich als solche erkannt habe.  Es ist mal wieder eine sehr innovative und vielseitig einsetzbare Erweiterung des Protokolls. Ich hoffe, dass mehr Clients die Möglichkeiten nutzen werden.

Was mir bei meinen Recherchen auffiel ist, dass man de facto keine Übersicht hat, was alles im im jabber:iq:private-Namespace auf dem Server unter meinem Account abgespeichert wurde. Das bedeutet, ohne die Namespaces der jeweiligen Funktion, kommt man also nicht so einfach an die Daten ran. Ich bleibe da mal dran, ob sich dazu noch Infos finden lassen. Darüber hinaus wurde ich in einem MUC auf die Idee gebracht, die Nutzerdatenbank eines großen Jabber-Knotens auf die Namespaces (und nur diese -> Datenschutz) innerhalb des jeweiligen privaten XML-Bereiches mit einem Script zu durchforsten - somit ließen sich ggf. noch weitere Anwendungsgebiete zu finden. Mal sehen, ob ich da was deichseln kann. (Update, 05.05.2011: Also auf meinem Server habe ich für das storage-Element keine weiteren Einträge gefunden.)

Wenn ich etwas neues herausgefunden habe, werde ich diesen Beitrag entsprechend erweitern. Bis dahin: Viel Spaß mit XMPP!

 

Nachtrag, 05.05.2011: XEP-0083: Nested Roster Groups nutzt ebenfalls den private-Namespace, allerdings ohne ein Storage-Element.

4Mai/110

Vacuum IM – ein recht unbekannter Jabber-Client

Unter vacuum-im.org (hier die englische Google Code Seite) findet man einen echt brauchbaren XMPP Client - natürlich Open Source und unter Linux und Windows lauffähig.

Ich würde sagen, er ist für Leute, die viel mit XMPP rumspielen und vielleicht auch einen eigenen Server haben sehr interessanter, da er z.B. Service-Disco sehr gut beherrscht und sauber auflistet, was ein Client/Server kann. Viele Details werden leicht erreichbar aufgelistet. Darüber hinaus sind noch Nettigkeiten wie Kommentare zu einzelnen Nutzern möglich. Generell bietet das Programm eine recht aufgeräumte, wenn auch nicht immer ganz praktische Oberfläche. Die Gestaltung des Nachrichtenfensters ist sehr schick gemacht (sieht in etwa so aus wie bei Swift IM).

Nun, ich denke, dass man den Client ruhig mal auf dem PC haben kann, ein Blick darauf schadet dem geneigten Nutzer nicht. Mal sehen, wie sich das Projekt noch weiter entwickelt – Abwarten und Tee trinken.
Was mir daran fehlt? Leider kein XEP-0184 (Message Delivery Receipts) (Nachtrag: laut Entwicklern kommt das noch) und kein GPG, von XEP-0198 (Stream Management) ganz zu schweigen. Local Storage, wie man es von Psi+ und Miranda kennt, kann er leider nicht (oder ich habe es noch nicht entdeckt *g*).

Ich für meinen Teil schätze das Programm im Moment, auch wenn ich z.B. keine OTR-Verbindung zu Pidgin aufgebaut bekomme (hier muss eindeutig mal eine XEP her).

Schön jedenfalls, die Diversität der Clients zu sehen und zu erkennen, dass es überall noch Platz für neue, gute Ideen und Umsetzungen gibt. Weiter so!

Updates: Link zur Google Code Seite; Korrektur bzgl. Entwicklern; Lizenz+Plattformen; Miranda kann auch Local Storage; Message Delivery Receipts sind für eine zukünftige Version geplant

3Mai/110

1,95583…

1,95583

Zähle ich langsam zu "den Alten", wenn ich diese Zahl noch im Kopf habe und vermutlich auch nie vergessen werde?