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.
Vor einiger Zeit entdeckte ich bei irgendjemandem in der Suppe ein Zitat, welches wieder mal sehr schön einfach die Welt erklärt. Leider verlor ich es dann aus den Augen, habe es jedoch wiedergefunden, und statt es nur zu reposten, möchte ich es langlebiger hier festhalten:
Die wohlfeilste Art des Stolzes hingegen ist der Nationalstolz. Denn er verrät in dem damit Behafteten den Mangel an individuellen Eigenschaften, auf die er stolz sein könnte, indem er sonst nicht zu dem greifen würde, was er mit so vielen Millionen teilt. Wer bedeutende persönliche Vorzüge besitzt, wird vielmehr die Fehler seiner eigenen Nation, da er sie beständig vor Augen hat, am deutlichsten erkennen. Aber jeder erbärmliche Tropf, der nichts in der Welt hat, darauf er stolz sein könnte, ergreift das letzte Mittel, auf die Nation, der er gerade angehört, stolz zu sein. Hieran erholt er sich und ist nun dankbarlich bereit, alle Fehler und Torheiten, die ihr eigen sind, mit Händen und Füßen zu verteidigen. ― Arthur Schopenhauer
Jetzt, da die Affero GPLv3 erschienen ist, denke ich ernsthaft an ein nächstes Harvester-Release, ist ja schliesslich Software as a service.
Danach sollte der Code aber wirklich ein Clean-Up. Im jetzigen Zustand funktioniert er zwar gut, aber falls mal jemand reinguckt, ist mir das eher peinlich. Dabei würde ich gleich einen schicken Datenbankabstraktionslayer benutzen. Naturgemäß greife ich dafür zu Momomoto, da aber einige Harvester-Hoster auf MySQL schwören, kann ich diese PostgreSQL-spezifische Bibliothek nicht einsetzen. Zum Glück gibt es für Ruby aber eine Menge Alternativen, siehe Wikipedia.
Ich hatte den Harvester zwischenzeitlich schon in C++ und in Erlang begonnen. Falls sich Mithacker finden, dann ist das Motivation, ansonsten gehts in Ruby weitaus schneller.
Dank toidinamai ist der Harvester jetzt auch unter blog-harvester.de erreichbar. Jetzt können sich alle Nutzer die Adresse besser merken, ist es doch für unterwegs oder die Ewiggestrigen ohne Feedaggregator gedacht.
Achja. Ich wünsche mir noch C++-Götter mit zuviel Zeit für Harvester-CC (git, gitweb), einem Rewrite, weil mir C++ gerade Spaß macht. Ich habe schon ziemlich genaue Ideen wie das werden soll, befasse mich aber zur Zeit noch mit dem Wrappen von libevent und udns. Dokumentieren kann ich auf Nachfrage. :-)
Eine weitere Idee hat ebenfalls toidinamai gehabt: man könnte Anpassungen der dargestellten Datensätze per Javascript vornehmen und die persönlichen Einstellungen als Cookies speichern; ein bisschen mehr in Richtung web-basierter Feedreader, was der Harvester ja eigentlich auch ist. Wer hat Lust auf sowas?
Damit das Web endlich mal Erfolg hat, muss dieses nervige Flash-Format verschwinden. Es gibt ja nicht wenige Menschen, denen Implementationen verwehrt sind, oder die aus rein ideologischen Gründen das entsprechende Plugin nicht installieren. Ich selbst habe mich nach dem Hype um Videoportale hingegeben und das Flash-Plugin installiert.
Eine Alternative ist da SVG, was ein offener XML-Standard ist und wofür schon mehrere Open Source-Implementationen existieren, dank Firefox auch halbwegs verbreitet und fortgeschritten.
Folgendes Beispiel ist inline direkt im XHTML (darf kein HTML sein), sogar CSS & JavaScript stecken im SVG. View Page Source! Es sollte mindestens auf neueren Mozillas laufen, Browser installieren ist nicht Ziel dieses Experiments.
Mit der Performance bin ich überhaupt noch nicht zufrieden. In dieser Größe saugt es schon recht viel Rechenzeit, in doppelter Größe ruckelt es extrem. Dabei ändern sich die Balken nur alle 40 ms, was 25 Schritte pro Sekunde ausmachen sollte.
Wer jetzt auch Lust auf SVG bekommen hat: ich bin an Erfahrungsaustausch interessiert.