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

17Feb/110

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.

15Feb/110

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:

XMPP-Logo

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].

veröffentlicht unter: Last-Crusade.de, Software keine Kommentare
15Feb/111

Unterschiede zwischen Jabber und XMPP


XMPP-Logo
versus
Jabber-Logo

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].

veröffentlicht unter: Jabber/XMPP, Software 1 Kommentar
9Feb/110

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...

veröffentlicht unter: Allgemein, Öko, Unser Planet keine Kommentare
6Feb/110

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 ;-)

6Feb/110

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.