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.
- 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.
- 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!
- 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.
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
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?
Swift 1.0 Released
Gestern wurde der OpenSource XMPP/Jabber-Client Swift in seiner ersten "reifen" Version 1.0 herausgegeben.
Bei Swift handelt es sich um einen sehr schlicht gehaltenen, aber technisch sehr interessanten und leistungsfähigen Jabber-Client.
Er ist besonders für Leute geeignet, die sich keinerlei Gedanken um das wie machen wollen, sondern nur um das dass - er bietet kaum Einstellmöglichkeiten, sondern funktioniert einfach.
Mehr Infos und Download unter: www.swift.im
Swift Kontaktliste
Swift Chatfenster
(Quelle der Bilder: swift.im)
Persönliche Meinung: Sehr guter Client "für die Massen", einfach, schick und technisch einwandfrei.
Was richtige "Power-User" wohl abhalten wird, sind der (tw. noch) fehlende Funktionen wie GPG-Unterstützung, kein Message Delivery Receipt (dafür aber partiell Stream Management!) oder auch LocalStorage. Derzeit unterstützt der Client nur einen Account gleichzeitig, wer mehr hat, guckt in die Röhre. Das wird sich aber vielleicht schon mit dem diesjährigen GSoC ändern. Generell läuft das Programm allen gängigen Betriebssystemen. Einfach mal ausprobieren!
Beer4Code – The winner is…
Und der nächste Begünstigte meines Project: Beer4Code ist:
LibreOffice, bzw. die Document Foundation (via dem deutschen OOo-Verein). Prost!
Ich hoffe, dass sie das gesammelte Geld in die Usability stecken, da wurde das Projekt vom Platzhirschen abgehängt...
Es ist übrigens gar nicht so einfach zu spenden, wenn alle nur Paypal annehmen, man selbst es aber boykottiert... Darum verzögert sich das Projekt leider ein wenig.
Einbindung von SVGs mit Fallback in HTML
Ich habe gerade auf ein paar Seiten hier im WordPress SVG-Graphiken integriert. Das ist leider gar nicht sooo einfach und hat noch ein paar Hürden.
<object data="http://www.last-crusade.de/wp-content/uploads/2011/last-crusade/jabber_xmpp/xmpp_logo.svg" type="image/svg+xml" width="100" height="103"><img width="100" height="103" src="http://www.last-crusade.de/wp-content/uploads/2011/last-crusade/jabber_xmpp/xmpp_logo.svg.png" alt="XMPP-Logo"></object>
Sieht folgendermaßen aus:
In Browsern, die SVG noch nicht unterstützen (*hust*verflixter IE*hust*), wird statt dessen das PNG angezeigt. Funktioniert soweit ganz gut, getestet mit Opera 11, Firefox 3.6 (und IE8 mit Fallback). Googles Chrome verschluckt sich ein wenig an der Größenangabe vom SVG (also width und height), wenn ich es richtig sehe, will er auf die Größe, welche im SVG selbst definiert ist, zurückgreifen und stellt dann nur den definierten Ausschnitt dar. Auch wenn das Ganze vermutlich bei Weitem nicht die schönste Umsetzung ist, halte ich dieses Verhalten schlicht und ergreifend für falsch. Nun, soweit mal der Stand seitens HTML.
Dass man in WordPress aber generell keine SVGs in die Mediathek laden kann, hat mich schon ein wenig enttäuscht - da ist noch Nachholbedarf, Jungs & Mädels! 
Das XMPP-Logo steht unter dem Copyright der XSF, vgl. [1], [2].
Unterschiede zwischen Jabber und XMPP
versus
Was sind eigentlich die Unterschiede zwischen Jabber und dem XMPP-Standard?
Diese Frage haben sich bestimmt einige schon gestellt. Die Suche im Internet führte (jedenfalls mich) auf die Schnelle nicht zu einer befriedigenden Antwort. Entweder werden die Begriffe gleichgesetzt oder aber XMPP wird nur als die "standardisierte" Version von Jabber bezeichnet.
Nun, das stimmt natürlich auch mehr oder minder. Und dass die Unterschiede überschaubar sein würden, davon konnte ausgegangen werden. Schließlich ist aus dem in der Community entwickelten Jabber das von der IETF offiziell abgesegnete XMPP geworden. Nun bin ich auf eine Auflistung der Unterschiede gestoßen - am dafür naheliegendsten Ort, nämlich dem Standard-RFC selbst (RFC3920). Hier einmal kurz (und hoffentlich korrekt 
) zusammengefasst, was dort so aufgelistet wird:
Channel Encryption
Bei Jabber war SSL vorgesehen. Bei XMPP wurde der "Nachfolger" TLS vorgeschrieben.
Authentication
Beim XMPP wurde das standardisierte SASL-Verfahren für die Authentifizierung festgelegt, bei Jabber wurde diese wohl in einer selbstgebackenen Lösung realisiert. Für die Server-zu-Server Verbindung wurde vor der Standardisierung kein vollständiges Verfahren festgelegt. Auch hier springt bei XMPP SASL in die Presche.
Resource Binding
Das Hinzufügen der vorgeschriebenen Ressource-ID war früher Teil des Authentifizierungs-Mechanismus, heute wurde dafür ein eigener Namespace definiert
JID Processing
Die Verarbeitung von JID's waren schlecht oder gar nicht definiert. Dieser Missstand wurde im XMPP behoben.
Error Handling
Im XMPP wurde ein erweiterter Mechanismus eingeführt, welcher sich um die Fehlermeldung innerhalb von Streams und Stanzas kümmert. In Jabber wurde hier wohl mit HTTP-ähnlichen Error-Codes verwendet.
Internationalization
Auch wenn UTF-8 schon seit eh und je in Jabber verwendet wurden, wurde keine Möglichkeit vorgesehen, um die Sprache des menschenlesbaren Parts zu definieren. Hierfür wurde im Standard ein "xml:lang"-Attribut eingeführt.
Stream Version Attribute
XMPP führt für Streams eine Versionierung ein, welche es beispielsweise ermöglichen soll, Rückschlüsse auf die Unterstützung für verschiedene Authentifizierungs- und Verschlüsselungsmechanismen zu signalisieren.
So, mehr wird im RFC nicht aufgelistet. Klingt ja nach recht sinnvollen Änderungen, die sie da vorgenommen haben. Vielleicht hilft diese Zusammenstellung ja mal dem Einen oder Anderen, der eine Präsentation oder ähnliches über das Protokoll halten will oder sich einfach auch fragte, was sich wohl geändert haben mag. Fest steht jedenfalls, dass der Name Jabber (zu deutsch: plappern, quasseln) wesentlich leichter von der Zunge geht, als XMPP - von daher wird er wohl (zu Recht) langfristig ein Synonym hierfür bleiben.
Das XMPP-Logo steht unter dem Copyright der XSF, vgl. [1], [2].
Gezielte Vergeudung von Ressourcen
Es ist schon traurig, wie heutzutage noch mit den kostbaren und durchaus begrenzten Ressourcen dieser Welt umgegangen wird. Besonders schlimm finde ich, wenn reines Marketing und die damit verbundene Gewinngier dazu führen. Was ich damit meine? Das will ich kurz erklären, vielleicht ist es dem Einen oder Anderen ja so gar nicht bewusst.
Wenn heutzutage beispielsweise eine neue Generation an Computerprozessoren das Licht der Welt erblickt, bieten die großen Hersteller wie Intel oder AMD diese in verschiedenen Ausführungen an, gestaffelt nach Leistung, Funktionsumfang und dem daraus resultierend Preis. Was hier aber traurige Wahrheit ist, ist folgendes: Es gibt meist eigentlich nur zwei oder drei verschiedene Ausführungen, der Rest wird einfach "kastriert", Funktionen werden also auf den Chips deaktiviert und/oder die Leistung einfach gedrosselt, damit diese den teuren Modellen vorbehalten bleiben. Das heißt also, dass die bessere Technik da wäre, wenn man sie nicht gezielt abklemmen würde. Und das ist finde ich eine Schande. Die Chips würden mehr leisten, man hätte mehr von seinem Geld und man bräuchte mitunter nicht so schnell einen neuen Rechenkern, weil die Geschwindigkeit des Alten ausreicht. Die Ressourcen für diese Dinger wurden aufgewendet und sie werden so verstümmelt, nur damit wir sie nicht so lange nutzen wollen/können. Das macht mich traurig und wütend. Meinetwegen sollen sie die CPUs doch teurer machen und nicht jedes Jahr eine neue Generation herausbringen, sondern lieber in längeren Abständen wirklich ausgereifte und bessere Chips auf den Markt werfen. Zumal sich dann auch Optimierungen der Software eher lohnen würden. Wir und die zukünftigen Generationen hätten unterm Strich wesentlich mehr davon.
Selbiges, wenn auch in etwas anderer Form gilt zum Beispiel auch für Kameras. Hier werden oftmals relativ ähnliche Modelle hergestellt (wenn auch ggf. in anderen Gehäusen), die alle das Gleiche könnten. Hier werden dann aber nicht die Chips beschnitten, sondern einfach die Software, welche auf den Kameras läuft. Und schon haben wir den gleichen Effekt.
Ich bin mir sicher, das gleiche Muster lässt sich auf viele andere Gebiete übertragen, die mir überhaupt nicht in den Sinn kommen.
Es ist einfach krank, was die Industrie mit unserem Planeten anstellt. Wir, oder spätestens unsere Nachfahren, werden aber dafür die Rechnung erhalten, keine Sorge...
XMPP/Jabber ist doof, weil…
Genug gelobt. Wollen wir doch mal motzen.
Jabber/XMPP ist doof, weil...
- ...die Clients (und auch Server) oft kleinere Bugs haben, die nerven.
- ...die praktischsten XEPs oftmals nur von wenigen Clients und Servern unterstützt werden.
- ...Dateitransfers über peer2peer-Verbindungen in "verwinkelten" Netzwerken nicht ohne Proxy funktionieren.
- ...Server und Clients merken teilweise erst spät, dass die Verbindung zwischen Ihnen abgebrochen ist, weil sie dafür relevate Protokollerweiterungen (z.B. XEP-0199) nicht implementieren und richtig nutzen, was dazu führen kann, dass Nachrichten verloren gehen (ebenfalls wegen nicht implementierter XEPs, vgl. hier).
- ...(menschenlesbares) XML ein gutes Stück mehr Bandbreite braucht, als eine kompakte Binärkodierung (kleiner Scherz am Rande dazu). Dies ließe sich durch eine sauberere Implementierung diverser Erweiterungen zwar reduzieren, aber es bleibt ein großer Overhead.
- ...es einfach zu wenig aktive Nutzer gibt.
- ...fast alle Entwickler von Servern und Clients ihr eigenes Süppchen kochen und nicht zusammenarbeiten.
So, wenn mir noch etwas einfällt, wird die Liste ergänzt. Soll mir keiner nachsagen, ich würde einseitig über Jabber schreiben
XMPP – Ein (abwärts-)kompatibles Protokoll
Wenn man Aufzählungen mit den Vorzügen von XMPP liest, sticht einem häufig die Eigenschaft der (Abwärts-) Kompatibilität ins Augen. Nun, aber was bedeutet das eigentlich?
Früher ging ich davon aus, dass damit schlicht und ergreifend gemeint ist, dass wenn sich das Protokoll ändern sollte, bzw. eine neue Version davon erscheint, alte "XMPP-1.0"-kompatible Clients trotzdem noch funktionieren werden. Das stimmt auch.
Allerdings ist das nicht der einzige Aspekt, der diese Eigenschaft erfüllt: Damit ist auch gemeint, dass das Extensible (!!!) Messaging and Presence Protocoll auch so designed ist, dass Clients/Server, die Erweiterungen (XEPs) anbieten nicht die Kompatibilität zu eben solchen, die diese nicht unterstützen, zunichte machen. Die schlichtest-mögliche Implementierung des Protokolls (Server oder Clientseitig) funktioniert immer noch mit der theoretisch "höchsten Ausbaustufe".
Das ist jetzt keine allzu große Erkenntnis, aber bei mir hat es ein Weilchen gedauert, bis ich den Zusammenhang erkannte.