Einfach um die Welt zu inspirieren habe ich doch mal mithilfe von Ramaze und XMPP4R einen web-basierten PEP-Aggregator gebaut. Dieser wurde auch schon auf Planet Jabber von Dave Cridland erwähnt.
Er wird natürlich exzessiv von User Tune dominiert, da hier die allermeisten Updates kommen.
Übrigens experimentiert Twitter auch mit PubSub.
Bei Jabber hat sich was getan. Etwas, worauf ich schon eine ganze Weile gewartet habe. Der neue ejabberd 2.0.0 bringt nämlich Unterstützung für Personal Eventing via Pubsub mit.
Dabei geht es um Updates, die gut in das Schema Presence passen würden. Würden, denn eigentlich möchte man nicht jeden Buddy im Roster mit für ihn unwichtigen Informationen belasten. Das würde ja gar nicht skalieren, denn Presence Stanzas erhält jeder im Roster, dem man die Erlaubnis erteilt hat.
Wie das bei Jabber eben so ist, abstrahiert man da und hat für solche Funktionalität Publish-Subscribe erfunden.
Davon hat der ein oder andere sicherlich schon mal gehört, wird es doch hier und da als ein Killer-Feature angepriesen. Das Konzept könnte man grob mit Mailinglisten umreissen: es gibt Entitäten mit Owner- oder Publisher-Berechtigung, und es gibt Subscriber. Alles ist XML und Konfigurierbarkeit ist vorgesehen. Nur fehlte bislang die Umsetzung.
Wenn man sich diese Erweiterung anschaut, dann wird man ganz schnell von Komplexität, insbesondere was die Einstellungsmöglichkeiten betrifft, erschlagen. Soviel braucht man nicht um seine derzeitige Stimmung oder den aktuellen Musiktitel zu publizieren. Ausserdem trifft die Menge der Empfänger ganz gut auf einen Teil des Rosters zu. Deshalb hat man sich eben jenes PEP ausgedacht, ein rudimentäres Publish-Subscribe.
Das funktioniert nun so, dass man selbst, also die eigene Jabber-Id ein Pubsub-Knoten ist. Wenn der eigene Server das kann (findet man mit Service Discovery raus), dann braucht man dorthin einfach nur drauflospublizieren.
Das mit dem Empfangen gestaltet sich schon etwas komplizierter. Man hat dabei wieder mehrere Jabber-Grundsätze bedacht.
Es muss für viele Interessenten und viele Updates gut skalieren. Deshalb muss irgendwie herausgefunden werden, wer an den Informationen interessiert ist.
Man hat wieder einen großen Teil der Komplexität den Servern überlassen. Die übernehmen hier nicht nur das entgegennehmen und verteilen, sondern auch die Entscheidung, an wen verteilt wird.
Und wie bekundet man nun Interesse an Informationen?
Zuerst einmal sollte gesagt werden, dass diese Strukturen immer mit XML-Namespaces typisiert werden. Anhand derer wird nun unterschieden und wenn man sie verarbeiten kann, dann kündigt man das in der Service Discovery an. Für PEP hängt man da noch ein +notify dran.
Wenn man also beispielsweise an aktuellen Musiktiteln (http://jabber.org/protocol/tune) interessiert ist, dann wird da http://jabber.org/protocol/tune+notify draus.
Service Discovery ist aber nix was man in einer <presence/> mitschickt, dafür wäre es ein bisschen zu gewichtig. Die muss aktiv abgefragt werden (dafür gibts bei Jabber die dritte Art Pakete: <iq/>).
Hier hätten wir schon den nächsten Flaschenhals. Mein Server kann doch nicht jeden Buddy einzeln abfragen.
Dafür hat man sich einen Cache-Mechanismus einfallen lassen: Entity Capabilities. Hierbei werden die Informationen der Service Discovery zusammengehashed. Das kann irgendwie passieren, es muss nur halbwegs eindeutig sein. Zirka so eindeutig, dass gleiche Clients in gleichen Versionen mit gleichen Einstellungen mit, und darauf liegt eben der Fokus, gleichen Features den selben Hash haben.
Trifft man (im Falle von PEP der eigene Server) nun auf einen unbekannten Hash, so holt man sich die unterstützten Features des Senders und hält sie für weitere Clients mit dem gleichen Hash vor.
Zurück zu PEP: man muss also die Namespaces der gewünschten Informationen in Service Discovery ausspucken und schon erhält man Updates. Wenn man Empfänger ist, dann muss es der eigene Server auch gar nicht unterstützen. Aber zugucken ist ja langweilig.
Laut turbo24prg kann Pidgin bereits User Tune empfangen. Dies und User Mood können Psi und Gajim auch. Gajim kann auch noch User Activity und die SVN-Version seit ein paar Tagen auch noch publizieren. Bewundern kann man das dann in den Popups im Roster.
Adium zeigt auch irgendetwas an, laut klobs.
Aber die Zukunft wird uns noch mehr bringen. User Viewing ist für den aktuellen Film, User Gaming für das aktuelle Spiel und User Chatting informiert über aktuelle IRC- und MUC-Chats. Wer sich jetzt an den Kopf greift, der versteht auch Dienste wie Twitter nicht. Ich übrigens auch nicht.
Sinnvoller wirds dann schon mit User Browsing, was einfach mal URLs austauschen ist. Ich bin gespannt, ob das effizient benutzbar umgesetzt wird. Richtig interessant, und das finde ich eine wirklich interessante Anwendung, wird dann noch File Repository and Sharing.
Schon jetzt hätte ich Lust einen Web-basierten Aggregator für Tune, Mood und Activity zu bauen. Das wäre viel weniger Aufwand als ihn beispielsweise der Harvester erforderte. Aber noch benutzt PEP niemand. Noch unterstützen es zu wenig Server. Abwarten, bis die soziale Welle über Jabber rollt.
So langsam glaube ich wirklich, Jabber-Clients könnten in ein paar Jahren die Dienste ablösen, die sich Social Networking oder Web 2.0 nennen. Ich bin einerseits gespannt, ob wir dann immernoch auf kleinen, von Privatpersonen betriebenen Server hängen, oder wir kommerzielle Infrastruktur verwenden werden, so wie das beim heutigen Web 2.0 der Fall ist. Ausserdem spannend, wie das User Interface zukünftiger Jabber-Clients aussehen wird. Es bleibt ja scheinbar nicht beim lediglichen Message & Presence. Social Networks haben ein schickes 2.0-Design in Pastellfarben, alles ausserhalb des Browsers sollte sich aber einheitlich in das restliche GUI einfügen. Aber das ist wohl generell die Frage nach dem UI der Zukunft.
After a bicycle trip to Prague...
I finally got my Jabbim T-Shirt!
Thanks to spike411 for meeting me in the beautiful but tourist-crowded town centre.
Vojtech Vobr has published the source of the famous Jabber Disk service. This is a very nice Jabber toy, and is usable with today's clients. And now other servers can provide online file storage!
If you really haven't experienced it yet, point your Jabber Service Discovery to disk.jabbim.cz!
Seit gestern ist XMPP4R 0.3 draussen. Lucas bloggt auch darüber.
Zwischen 0.2 und 0.3 liegt ungefähr ein dreiviertel Jahr, das ist nicht unbedingt im Sinne von "Release early, release often". Die prägenden Features waren auch schon längst implementiert, jedoch fanden einige ein Redesign sinnvoll. Und so fand ich es sinnvoll, kein Release vor einem Redesign zu machen. Leider war die Beteiligung am Code dann nicht besonders hoch, eigentlich wirklich sehr niedrig, so daß sich bei mir Frustration breitmachte.
Es gab dann aber doch Phasen in denen ich es doch vorangebracht habe. Hinterher konnte ich noch ein bisschen Test Coverage ausbauen und ein paar klitzekleine Ungereimtheiten beseitigen.
Und nun ist es draussen. Ich persönliche empfinde das als eine große Entlastung, denn es war auf keinen Fall ein gutes Gefühl das so lange vor mir herzuschieben wo doch tatsächlich ein paar Leute mit XMPP4R entwickeln. Endlich muss ich nicht mehr trunk empfehlen.
Die nächsten Releases können nun etwas sorgenfreier angegangen werden.