Der Schockwellenreiter Rotating Header Image

Alternative zu den Webriesen (2)

Die One-Slide-Show »Alternative zu den Webriesen« (wir berichteten) hat mir keine Ruhe gelassen. Natürlich hat Wieland Baurecker recht, RSS oder Atom ist der Schlüssel zu einem Peer-to-Peer Sozialem Netz (sollte ich als Autor eines Büchleins über RSS und Atom eigentlich von alleine drauf gekommen sein): Denn ich hatte bisher immer ein ungutes Gefühl bei meiner lapidaren Feststellung, daß man bei statischen Seiten die Kommentare eben als Webservice »zukaufen« müßte (vor allem, weil ich bei Haloscan ja dermaßen auf die Schnauze gefallen bin). Warum kommentiert man nicht im Feedreader (der als Webserver auf dem Desktop läuft)? Dieser muß dann (zum Beispiel via XMPP) beobachten, wann der Redaktionsserver des Kommentierten (im Zweifelsfalle ebenfalls ein Webserver auf dem Desktop und daher nicht permanent online) zu erreichen ist und ihn — auch wieder via XMPP — benachrichtigen, daß er kommentiert wurde. Was dieser Redaktionsserver dann damit anstellt, ist seine Sache.

Je länger ich darüber nachdenke, desto einfacher wird es eigentlich: Die benötigten offenen Protokolle für solch ein Peer-to-Peer Soziales Netz scheinen sich auf RSS/Atom und XMPP zu beschränken. (Eventuell ist für einige Anwendungen noch XML-RPC notwendig, da muß ich noch einmal darüber nachdenken. Aber ich glaube eher nicht.)

Übrigens zum Thema Desktop-Server: Eigentlich kann man fast alles und jede Web-Entwicklungsumgebung dazu aufbohren. Meine bisherigen Kandidaten sind (weil sie schon ziemlich viel von dem benötigten mitbringen): Winers OPML Editor (ein wenig altmodisch, aber ich liebe das Teil — Frontier hat mich seit meinen ersten Schritten im Web vor ca. 15 Jahren immer begleitet — und es bringt einen Feedreader, ein Static Site Framework und Unterstützung für XMPP und XML-RPC von Hause aus mit) und Googles App Engine (mit Django). Sicher tut es auch eine lokale Rails-Installation oder jede beliebige MAMP- oder XAMP-Umgebung mit einem geeigneten PHP-Framework, aber mit Rails wie auch mit PHP-Frameworks kenne ich mich nicht so gut aus.

Und sicher lassen sich auch einige (erweiterbare) CMS wie beispielsweise Drupal oder sogar Wikis wie das DokuWiki oder MoinMoin (leider wird MoinX nicht mehr weiterentwickelt, das wäre ein Kandidat gewesen) zu so etwas aufbohren.

Wie immer stehen diese unfertigen Gedanken zum einen hier, damit ich sie nicht vergesse. Zum zweiten aber, damit niemand auf die Idee kommt, sich so etwas patentieren zu lassen. Und zum Dritten natürlich, weil ich auf Eure Kommentare hoffe. Denn nur so kann es besser werden.

Teilen:
  • Facebook
  • del.icio.us
  • Google Bookmarks
  • MySpace
  • PDF
  • RSS
  • Technorati
  • email
  • Wikio
  • Digg
  • Identi.ca
  • MisterWong.DE
  • Posterous
  • Twitter
  • Print
  • Yigg
  • LinkedIn
  • FriendFeed
  • Tumblr

8 Kommentare

  1. LH sagt:

    “Eigentlich kann man fast alles und jede Web-Entwicklungsumgebung dazu aufbohren”

    Kann man, sollte es aber auf keinen Fall tun. Die normalen Entwicklungsumgebungen sind absolut unsicher, ein Einfallstor für jeden der böswilliges Vorhat. Aus gutem Grund sind sie alle deutlich als Entwicklungsumgebungen gekennzeichnet, die man NICHT für einen Echtbetrieb nutzen solle.

    Sie sind oft unsicher konfiguriert, bringen zu viele nicht benötigte Funktionen mit (XAMPP) welche weietre potentielle Sicherheitsprobleme aufwerfen, oder sind gleich komplett reine Testserver ohne Sicherheitsfunktionen (Google App Engine SDK und Django Runserver).

    Abgesehen natürlich von dem enormen Problem der Sicherheitslücken auch in den stabilen Produkten. Natürlich kann man lokal z.B. Apache nutzen (abgesehen davon das unerfahrene Admins sehr viel falsch machen können, und ihr System direkt vom Start ab gefährden), aber abgesehen von den Problemen von XAMPP und co. allgemein sind eben auch Sicherheitslücken zu beachten. Wer spielt immer die neueste Version ein? Was ist wenn ein Majorrelease ansteht, der eine neue Config erfordert? Sind die Leute dazu überhaupt in der Lage?

    Ich sehe dem ganzen extrem kritisch entgegen. Der normale User ist am besten damit gediehnt wenn er rein garnichts von meinem PC aus ins Internet shared, nur das ist halbwegs sicher zu bekommen (und selbst das klappt oft schon nicht).
    Ein Server auf dem Desktop? Ich betreue selber Server, und halte das für puren Wahnsinn. Auf die Masse der User gesehen wäre diese Idee der größte Gau seit dem Internet Explorer 6…

    Hosting ist billig und überall zu bekommen, auch von vielen Firmen die vertrauenswürdig sind. Durch die vielen Firmen ist es zudem dezentral. Anders als Facebook interessieren sich Hoster auch nicht für die Daten.
    Da ist soetwas ideal aufgehoben, und nirgendwo sonst.
    Schon der höhere Stromverbrauch weil man den PC eben doch mal anlässt, kostet den User schon mehr als das Hosting bei einem professionelen Provider.

  2. Jörg Kantel sagt:

    Ich sehe das nicht so kritisch, da ich davon ausgehe, daß der Webserver hinter einem Router (mit NAT) und im Idealfall auch noch hinter einer Firewall versteckt ist. Und der OPML Editor oder das leider entschlafenen MoinX (mit ihren Ein-Klick-Installern auf dem Mac) funktionieren eigentlich ziemlich gut. Daher gehe ich davon aus, daß man dem »normalen« User so etwas auch als »fertige« Applikation anbietet.

    Aber natürlich hast Du mit den Hostern recht: Das wäre auch meine Ideal-Situation. Ein Redaktionsserver (dynamisch) bei einem Hoster und ein Produktionsserver (statisch) bei dem gleichen oder auch einem anderen Hoster (man kann sogar in die Cloud gehen und zum Beispiel einen Redaktionsserver bei Amazons EC2 oder Google (App Engine) laufen und eine Produktionsserver zum Beispiel auf Amazons S3 abgelegt haben. Aber ich denke, daß nicht jeder, der an Sozialen Netzen teilnehmen, auch einen Hosting-Vertrag abschließen will.

    Ein weiteres Problem bei den Desktop-Servern ist die Erreichbarkeit: DynDNS wäre eine Lösung, aber wirklich glücklich bin ich damit (noch) nicht.

  3. Roland sagt:

    Ein grosser Vorteil (oder Nachteil?) der Social Networks ist doch die Auffindbarkeit der einzelnen Teilnehmer. Wie soll das in einem reinen P2P-Netz abgebildet werden? Heutige P2P-Netze setzen immer auch eine Art zentrales Telefonbuch ein.
    Und wie soll das Problem der Suche gelöst werden? Temporär verfügbare Inhalte zu indizieren und auffindbar zu machen dürfte schwierig werden. Die meisten Benutzer sind es gewohnt, das Informationen ständig, 24/7, zugreifbar sind. Darunter würde die Akzeptanz eines solchen Netzwerkes leiden.

  4. Webmeister sagt:

    Für lokale Desktop-Server kann ich mich auch nicht wirklich begeistern.
    Bin ich dann mal unterwegs, so muss immer sichergestellt sein, dass der Rechner auf dem der Desktop-Server läuft auch eingeschaltet ist.

    Zuhause will ich mir eigentlich kein Rechenzentrum aufbauen. Es reicht, wenn mein Intranet-Server, welcher interne Daten verwaltet, unterhalten werden muss.
    Alle Daten die dann auch im Internet publiziert werden, verwalte ich lieber in einer Webanwendung, welche auf dem Webserver des Providers läuft.

  5. Jörg Kantel sagt:

    @Roland: In meinem Konzept dient der Webserver auf dem Desktop »nur« als Redaktionsserver, der Produktionsserver besteht aus statischen Seiten mit den Inhalten (auch der RSS-Feed ist »statisch«). Dieser kann durchaus 24/7 erreichbar sein (und sei es auf Amazon S3). Das ist das alte Konzept von Radio UserLand oder auch die Art, wie mein Weblog mit Frontier bis Mai 2009, bis zu meinem Umstieg auf WordPress, funktionierte. Ein klein wenig hatte ich allerdings gemogelt (und das ist eine Antwort auf den @Webmeister): Da es mir mit der Zeit zu mühsam wurde, die Daten ständig zwischen meinem Desktop zu Hause, meinem Desktop im Büro und meinem Laptop (wo überall Frontier als Webserver auf dem Desktop lief) via USB-Stick zu synchronisieren, habe ich diese Arbeit schon seit einigen Jahren der Dropbox überlassen (das mache ich übrigens bis heute so). ;-)

  6. Wichtig wäre mir vor allem eine Vielfalt an Möglichkeiten:
    - Datenmobilität: Einen reisebereiten Daten-Koffer mit dem ich schnell zu einem Hoster-Dienstleister meines Vertrauens wechseln kann.
    - Auswahl beim Werkzeug: Eine Auswahl wie bei Email und den Feedreader-Lösungen (Software, Web, PlugIns- oder wie auch immer).

    Die Grundlage für die Vielfalt ist ein Standard der alles zusammenhält.
    - Auch von daher finde ich es sehr sexy auf das bewährte RSS/OPML Format aufzubauen.

    Es ist wie ein dichter Knäul, aus dem verschiedenste Fäden herausgezogen werden. Der nächste wichtige Faden für mich ist: Wie könnte ein Benutzerinnen zentriertes Design für so eine Anwendung aussehen.

  7. Uhu sagt:

    Ist ein bisschen Off Topic, aber da Du es hier erwähntest: Was war das Problem mit Haloscan (außer daß die zu einem Bezahldienst geworden sind natürlich …) ? Klingt ja nach schwerwiegenderen Problemen.

  8. Jörg Kantel sagt:

    Wieso Bezahldienst? Bezahlt hatte ich immer schon, ich hatte von Anfang an einen Pro-Account. Dicht gemacht haben sie und meinen Account ungefragt an ECHO übergeben, die zumindest meine Monatsarchive unlesbar gemacht haben. Ich muß irgendwann einmal mit einem Script über alles Seiten fahren und das alte HaloScan-JavaScript rauslöschen. Ich bin ziemlich sauer auf die …

Einen Kommentar verfassen

Mit dem Absenden Ihres Kommentars willigen Sie ein, daß der angegebene Name, Ihre Email-Adresse und die IP-Adresse, die Ihrem Internetanschluß aktuell zugewiesen ist, von mir im Zusammenhang mit Ihrem Kommentar gespeichert werden. Die Email-Adresse und die IP-Adresse werden natürlich nicht veröffentlicht oder sonst weitergegeben.