Mittwoch, 20. Juli 2005
Gravatar.com ist tot, hoch lebe Gravatar/Foafatar!
Gravatar.com ist (war?) ein Service, der es jedem User anhand seiner E-Mail Erkennung ermöglichte, ein eigenes Bildchen auf anderen Blogs für seine Kommentare zu hinterlassen.
Technisch war das ein supersimples Ding: Jeder Weblogbesitzer musste sein Template nur so ändern, dass eine "http://gravatar.com/bild?email=XXX" URL als Bild angezeigt wird, wenn der User seine E-Mail Adresse hinterlassen hat.
Der Vorteil: Die Bilder werden, ohne dass das eigene Blog irgendwas parsen/suchen muss, sofort dargestellt. Und die Technik ist ultrasimpel.
Der Nachteil: Der Server, der die Bilder ausliefert muss nicht nur die ganze Arbeit machen (nämlich das passende Bild raussuchen für die email XXX), sondern kriegt zum einen eine Menge eingehenden Traffics und zum anderen eine Menge ausgehenden. Hier ist das Zauberwort "Menge", und nicht "Masse". Denn Gravatar bekommt nur kleine HTTP Requests rein, und antwortet mit einem kleinen HTTP Reponse, der nur weiterleitet. Das sind also üblicherweise an die 300 Byte für die Anfrage und 300 Byte für die Ausgabe.
Solange nur ein paar Blogger das machen, ist das Trafficmäßig also kein Problem. Sobald man aber davon ausgeht, dass mehrere hundert Blogger Einträge mit jeweils 10-20 Kommentare haben die mehrmals in der Stunde gelesen werden, kommt da doch einiges zusammen. Was Gravatar.com wohl letztlich auch das Genick gebrochen haben wird, da auch an Serverlast sicher einiges zusammenkommt und der Service ein freier war, der von jedem sehr einfach genutzt werden konnte.
Der wohl geneigte Blogger mag so eine Situation natürlich nicht akzeptieren und will seine liebgewonnenen Avatar-Bildchen der Kommentatoren zur einfachen Unterscheidung natürlich wiederhaben. Da ein freier Service wie obiger ohne Sponsoring oder finanzierte Mehrwertdienste nicht machbar ist, wird man wohl was eigenes nutzen müssen.
Alp Uckan hat dazu einen netten Artikel zu FOAFataren geschrieben, direkt mit Implementationsidee.
Der Grundsatz ist folgender: FOAF ist eine XML-formatierte Metabeschreibung, die soziale Informationen zu einer Person speichern kann. In einer solchen Datei legt ein Blogger (oder Erna Müller von nebenan, das ist ja egal) an, welche Personen er kennt ("Web of Trust"), was er für Hobbies hat, wo er wohnt (geolocation) und auch wie er aussieht. Diese XML-Datei speichert der Blogger auf seinem eigenen Server und erstellt einen Metalink in allen seinen HTML-Seiten, damit die anderen Benutzer (und Programme) wissen, wo sie die FOAF-Datei finden können.
Technisch war das ein supersimples Ding: Jeder Weblogbesitzer musste sein Template nur so ändern, dass eine "http://gravatar.com/bild?email=XXX" URL als Bild angezeigt wird, wenn der User seine E-Mail Adresse hinterlassen hat.
Der Vorteil: Die Bilder werden, ohne dass das eigene Blog irgendwas parsen/suchen muss, sofort dargestellt. Und die Technik ist ultrasimpel.
Der Nachteil: Der Server, der die Bilder ausliefert muss nicht nur die ganze Arbeit machen (nämlich das passende Bild raussuchen für die email XXX), sondern kriegt zum einen eine Menge eingehenden Traffics und zum anderen eine Menge ausgehenden. Hier ist das Zauberwort "Menge", und nicht "Masse". Denn Gravatar bekommt nur kleine HTTP Requests rein, und antwortet mit einem kleinen HTTP Reponse, der nur weiterleitet. Das sind also üblicherweise an die 300 Byte für die Anfrage und 300 Byte für die Ausgabe.
Solange nur ein paar Blogger das machen, ist das Trafficmäßig also kein Problem. Sobald man aber davon ausgeht, dass mehrere hundert Blogger Einträge mit jeweils 10-20 Kommentare haben die mehrmals in der Stunde gelesen werden, kommt da doch einiges zusammen. Was Gravatar.com wohl letztlich auch das Genick gebrochen haben wird, da auch an Serverlast sicher einiges zusammenkommt und der Service ein freier war, der von jedem sehr einfach genutzt werden konnte.
Der wohl geneigte Blogger mag so eine Situation natürlich nicht akzeptieren und will seine liebgewonnenen Avatar-Bildchen der Kommentatoren zur einfachen Unterscheidung natürlich wiederhaben. Da ein freier Service wie obiger ohne Sponsoring oder finanzierte Mehrwertdienste nicht machbar ist, wird man wohl was eigenes nutzen müssen.
Alp Uckan hat dazu einen netten Artikel zu FOAFataren geschrieben, direkt mit Implementationsidee.
Der Grundsatz ist folgender: FOAF ist eine XML-formatierte Metabeschreibung, die soziale Informationen zu einer Person speichern kann. In einer solchen Datei legt ein Blogger (oder Erna Müller von nebenan, das ist ja egal) an, welche Personen er kennt ("Web of Trust"), was er für Hobbies hat, wo er wohnt (geolocation) und auch wie er aussieht. Diese XML-Datei speichert der Blogger auf seinem eigenen Server und erstellt einen Metalink in allen seinen HTML-Seiten, damit die anderen Benutzer (und Programme) wissen, wo sie die FOAF-Datei finden können.
Da liegt der Gedanke natürlich nahe, diese Informationen doch auch bei Kommentaren auszuwerten. Schließlich hinterlassen Kommentatoren ja ihre eigene URL, also kann eine dynamische Skriptsprache wie PHP die Infos auch auswerten.
Ein Plugin hätte nun also zwei Möglichkeiten, dies auszuwerten:
1. Es erstellt ein eigenes "Bildweiterleitungsscript" á la gravatar.com: eine "foaf.php?url=http://...." auf dem eigenen Server gibt als HTTP Weiterleitung ein Bild aus. Dann kommt zumindest der Binärtraffic auch wieder vom Server des Kommentatoren.
2. Man sucht das Bild des Kommentatoren direkt an der Stelle im Blog per Scriptsprache raus, an der die Kommentare dargestellt werden.
Natürlich haben beide Varianten Vor- und Nachteile. Welche Methode Alps Script implementiert kann ich noch in Ermangelung des von mir nicht angeforderten Plugins natürlicht nicht sagen.
Methode 1 hat den Vorteil, dass die Kommentare direkt an den Browser ausgegeben werden, und die Avatar-Bildchen vom Browser durch separate kleine HTTP Requests nachgeladen werden können. Das ist nämlich die Schwachstelle von Lösung 2: Wenn irgendeine FremdURL Probleme macht, stockt die Ausgabe der Kommentare komplett, bis ein Timeout erreicht ist oder die FremdURL antwortet. Methode zwei erzeugt zudem das Problem, das für jedes einzelne Bildchen ein Request auf dem eigenen Server landet. Pro Kommentar zu einem Eintrag wäre das also ein Request, der jedesmal den PHP-Prozessor anschmeißt und XML-RPC oder andere Libraries einbinden muss.
Methode 2 hat also den Vorteil, Requestsparender zu laufen.
Beide Methoden kranken jedoch daran, dass der hohe Mini-Traffic nun auf dem eigenen Server abläuft. Denn pro Kommentar müssen mindestens 1, maximal 2 HTTP Requests gemacht werden: Einer, um die FOAF-Datei zu finden und einer, um die dann gefundene FOAF Datei zu öffnen und zu parsen.
Im kleinen Umfeld merkt man das nicht, aber in dem Bereich der "beliebtes Blog mit mehreren Kommentatoren" ist so eine dezentrale Eigenlösung sehr unperformant. Der arme eigene Server muss ständig HTTP Requests machen und kann dabei auf aller Art Netzprobleme stoßen, die den eigenen Server auch durch am Leben erhaltene Webserver-Childs stören kann.
Zum anderen stellt diese Lösung ein gewisses Sicherheitsproblem dar, denn die "bösen Kommentatoren" könnten ja in ihrer FOAF-Datei alles mögliche schreiben oder ungültige HTTP-Requests auflösen oder was auch immer. Zum anderen lassen sich die Informationen auf dem eigenen Server schlecht cachen, da sich der Speicherort der FOAF-Datei oder das Bild ja auch mal ändern könnte. Irgendwann muss man also einen etwaigen Cache immer neu validieren und dann den oben erwähnten Traffic erzeugen.
Als kleines Resümee: Eine sehr coole, geekige Lösung, die aber für den großflächigen Einsatz leider einem RPC (Remote Procedure Call) ähnelt und damit die bekannten Probleme verursacht: Es wird unter Last arschlangsam.
Ich finde Alps Lösung als Grundansatz sehr schön, aber eigentlich müsste so etwas als zentralisiertes Konzept erstellt werden und nicht als Bausatz für die eigene Seite. Vielleicht kann hier ja OpenID noch stärker zum Einsatz kommen und auf mehrere Serververbundnetze mit automatischem Mirroring oder was auch immer verteilt werden.
Am schönsten und einfachsten wäre es natürlich, wenn jemand einen solchen Service (oder gravatar.com) sponsort.
Ein Plugin hätte nun also zwei Möglichkeiten, dies auszuwerten:
1. Es erstellt ein eigenes "Bildweiterleitungsscript" á la gravatar.com: eine "foaf.php?url=http://...." auf dem eigenen Server gibt als HTTP Weiterleitung ein Bild aus. Dann kommt zumindest der Binärtraffic auch wieder vom Server des Kommentatoren.
2. Man sucht das Bild des Kommentatoren direkt an der Stelle im Blog per Scriptsprache raus, an der die Kommentare dargestellt werden.
Natürlich haben beide Varianten Vor- und Nachteile. Welche Methode Alps Script implementiert kann ich noch in Ermangelung des von mir nicht angeforderten Plugins natürlicht nicht sagen.
Methode 1 hat den Vorteil, dass die Kommentare direkt an den Browser ausgegeben werden, und die Avatar-Bildchen vom Browser durch separate kleine HTTP Requests nachgeladen werden können. Das ist nämlich die Schwachstelle von Lösung 2: Wenn irgendeine FremdURL Probleme macht, stockt die Ausgabe der Kommentare komplett, bis ein Timeout erreicht ist oder die FremdURL antwortet. Methode zwei erzeugt zudem das Problem, das für jedes einzelne Bildchen ein Request auf dem eigenen Server landet. Pro Kommentar zu einem Eintrag wäre das also ein Request, der jedesmal den PHP-Prozessor anschmeißt und XML-RPC oder andere Libraries einbinden muss.
Methode 2 hat also den Vorteil, Requestsparender zu laufen.
Beide Methoden kranken jedoch daran, dass der hohe Mini-Traffic nun auf dem eigenen Server abläuft. Denn pro Kommentar müssen mindestens 1, maximal 2 HTTP Requests gemacht werden: Einer, um die FOAF-Datei zu finden und einer, um die dann gefundene FOAF Datei zu öffnen und zu parsen.
Im kleinen Umfeld merkt man das nicht, aber in dem Bereich der "beliebtes Blog mit mehreren Kommentatoren" ist so eine dezentrale Eigenlösung sehr unperformant. Der arme eigene Server muss ständig HTTP Requests machen und kann dabei auf aller Art Netzprobleme stoßen, die den eigenen Server auch durch am Leben erhaltene Webserver-Childs stören kann.
Zum anderen stellt diese Lösung ein gewisses Sicherheitsproblem dar, denn die "bösen Kommentatoren" könnten ja in ihrer FOAF-Datei alles mögliche schreiben oder ungültige HTTP-Requests auflösen oder was auch immer. Zum anderen lassen sich die Informationen auf dem eigenen Server schlecht cachen, da sich der Speicherort der FOAF-Datei oder das Bild ja auch mal ändern könnte. Irgendwann muss man also einen etwaigen Cache immer neu validieren und dann den oben erwähnten Traffic erzeugen.
Als kleines Resümee: Eine sehr coole, geekige Lösung, die aber für den großflächigen Einsatz leider einem RPC (Remote Procedure Call) ähnelt und damit die bekannten Probleme verursacht: Es wird unter Last arschlangsam.
Ich finde Alps Lösung als Grundansatz sehr schön, aber eigentlich müsste so etwas als zentralisiertes Konzept erstellt werden und nicht als Bausatz für die eigene Seite. Vielleicht kann hier ja OpenID noch stärker zum Einsatz kommen und auf mehrere Serververbundnetze mit automatischem Mirroring oder was auch immer verteilt werden.
Am schönsten und einfachsten wäre es natürlich, wenn jemand einen solchen Service (oder gravatar.com) sponsort.
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Allerdings ist man dann genau so weit wie zuvor. Ändert der Anbieter ein bisschen was, bricht das ganze System zusammen.
Dem Anbieter gefällt diese Abhängigkeit.
Dem Benutzer eher nicht.
Dem Benutzer gefällt an so was jedenfalls, dass nicht der eigene Server in die Knie geht. Für eine Spielerei wie Avatare würde zumindest ich keine Bandbreite opfern wollen, wenn das so Parsing/Request-Intensiv ist.
