Im ersten Teil dieser Serie hatte ich vorgestellt, wie man mit Hilfe des OPML Editors statische und trotzdem Community-fähige Seiten erzeugen kann. Als Beispiel hatte ich ein P2P-flickr ausgewählt. Doch nicht immer baut man eine Website vom Grund auf neu. Gerade im wissenschaftlichen Umfeld hat man oft die Situation, daß der oder die Wissenschaftler sich im Vorfeld eine (Desktop-) Datenbank (z.B. FileMaker oder MS-Access) angelegt haben, die die Daten enthält, die nun ins Netz gestellt werden sollen. In diesem Falle halte ich es für ziemlich übertrieben, diese Datenbank noch einmal in Frontiers odb (object database) zu spiegeln, zumal ich Datenbanken per se mißtraue und Textdateien im (Unix-) Filesystem für die sicherste Datenbank der Welt halte.
Die erwähnten Desktop-Datenbanken sind aber in der Lage, ihre Daten als Textdateien (mit ein wenig drumherum) herauszugeben, so daß eine Template-Engine in der Lage ist, daraus mit Hilfe eines Templates Webseiten herauszurendern. Bis vor kurzem war das Perl Template Toolkit für solche Arbeiten das Werkzeug meiner Wahl, denn es ist wirklich sehr, sehr leistungsfähig. Doch leider erkauft man sich diese Leistungsfähigkeit mit einem schwerwiegenden Nachteil. Bedingt durch die Komplexität ist der gemeine Wissenschaftler an sich nicht in der Lage, dieses Toolkit ohne Hilfe einer EDV-Abteilung zu konfigurieren und seine Webseiten herauszuschreiben. Frontier resp. der OPML Editor hingegen sind erst einmal so einfach, daß nach kurzer Einarbeitung jeder damit arbeiten kann.
Und hier kommt Matt Neuburgs RubyFrontier ins Spiel. Es ist ähnlich einfach wie Frontier oder der OPML Editor (es ist ja schließlich so etwas wie ein Frontier-Klon), nur, daß das Tool statt auf einer odb auf Text-Dateien arbeitet (Outlines erwartet RubyFrontier als OPML-Dateien … und das sind XML-Dateien, also auch Text pur). Meine bisherige Strategie sieht so aus: Der eigentliche Content wird — wie auch immer (z.B. über FileMaker) — aufbereitet und auf einem Rechner im Netzwerk, den RubyFrontier erreichen kann, zur Verfügung gestellt (in einigen Fällen habe ich noch ein Versionsverwaltungssystem dazwischengeschaltet, um die Konsistenz der Daten zu sichern). Dann läuft die Template Engine darüber und erstellt statische Seiten für die Webpräsenz. So lassen sich relativ schnell und ziemlich einfach auch größere Sammlungen ins Netz stellen — warum nicht auch ein P2P-flickr?
Für den Community-Teil gilt das im ersten Teil dieses Beitrags gesagte, aber dieses Beispiel zeigt auch, daß die einzelnen Teilnehmer solch eines P2P-Netzes nicht die gleichen Werkzeuge benutzen müssen, um miteinander kommunizieren zu können. Denn egal, ob ich RubyFrontier, den OPML Editor, das Perl Template Toolkit oder Django benutze, solange ich mich auf offene Standards und Protokolle einige, funktioniert auch die Kommunikation.
(In meinen Kommentaren zum ersten Teil schlug Thomas vor, PubSubHubbub statt XMPP zu nutzen, ein interessanter Ansatz, den ich weiterverfolgen werde.)
What’s next? Seit einiger Zeit lade ich alle meine Photos nicht nur zu flickr, sondern — als Backup meiner lokalen Festplatte — auch auf Amazons S3 hoch. Um Ruby zu lernen, werde ich mich — sobald ich wieder etwas Luft habe — mal an ein Ruby-Script versuchen, das daraus mit Hilfe von RubyFrontier eine statische P2P-flickr-Instanz (mit Photos und Videos) zaubert und die mit der im ersten Teil entworfenen OPML-Editor-basierten P2P-flickr-Instanz »spricht«. Wäre doch erst einmal ein netter Anfang …
Ansonsten habe ich viel vor: Ich besitze zum Beispiel eine große Sammlung historischer (Musik-) Noten, die ich so relativ problemlos ins Netz stellen könnte.
Und über die Webseiten, die in meinem beruflichen Umfeld mit RubyFrontier erstellt werden, berichte ich, sobald sie öffentlich zugänglich sind.
