RSS Feed
abonnieren.
Suche
Wunschzettel
Weblogeinträge
ReferenzenPersonal Avatar (aka Pavatar) - unabhängige Avatare | 23. Oktober 2005 um 23:21 Uhr
Gerade stelle ich wieder Fest, dass gravatar.com wieder einmal nicht erreichbar ist. Ich denke es ist ein guter Zeitpunkt meine Alternative vorzustellen:
Ich habe eine Spezifikation geschrieben, mit welcher ich einen Weg beschreibe wie man Avatare, verteilt über das ganze Internet, ohne einen Zentralen dienst nutzen kann. Hier erst einmal der Link zur vorläufigen Spezifikation: http://pavatar.com/spec, dort wird es auch immer die neueste Version geben. Es wird sich von der Herangehensweise her nichts mehr ändern, höchstens von der Ausdrucksweise.
Ich habe lange daran gegrübelt und geschrieben und geändert und wieder neues dazu geschrieben. An dieser Stelle möchte ich mich bei Christian Kruse, Tim Tepaße, Christian Seiler und Matthias Schäfer herzlich bedanken, die mir wirklich super mit Hinweisen, und vor allem mit dem Englischen geholfen haben.
Die Vorteile
Natürlich hat meine Lösung Vorteile gegenüber einem zentralen Dienst, hier ein paar die mir gerade so einfallen:
- Nicht abhängig von der Erreichbarkeit einer einzelnen Seite
- Die Pavatare können auf dem eigenen Webspace gehostet werden
- Niemand kann Profile von Nutzern von Pavataren erstellen, da das ganze dezentral aufgebaut ist. Somit sind sie nahezu Anonym
- Der Webmaster kann selbst entscheiden welche Pavatare auf seiner Seite angezeigt werden
- Der Kommentator kann selbst entscheiden wo seine Pavatare nicht angezeigt werden sollen
- Durch das caching werden die Pavatare vom gleichen Server wie die Seite selbst geladen und sind somit sofort da
- Durch conditional gets (GET-Requests mit
If-Modified-SinceoderIf-None-Match) wird die Geschwindigkeit der Auslieferung der seiten nicht so massiv beeinträchtigt wie bei einem zentralen Dienst
Ich denke das waren die wichtigsten Neuerungen, es gibt wahrscheinlich aber noch viel mehr.
Aufruf an die Plugin Programmierer
Natürlich hilft eine solche Spezifikation alleine nichts, sie muss in bestehende und zukünftige Software implementiert werden. Bisher gibt es zwei Implementationen: Classic Forum und Block, beide von Christian Kruse.
Deshalb rufe ich alle Pluginschreiber dazu auf Plugins für ihre Lieblingssoftware zu schreiben, die es den Nutzern dieser erlaubt Pavatare zu nutzen.
Technischer Hintergrund
Es wird anhand der vom Kommentator angegebenen Website URL versucht die URL des Pavatars zu »erraten«. Die Technik dahinter orientiert sich grundsätzlich an drei bestehenden Systemen. Vom Pingback wurde die Möglichkeit der mitteilung der Pavatar URL per Header und <link> übernommen. Von Favicon die Möglichkeit das Pavatar im Document Root zu hosten.
Wie mache ich meine Seite Pavatar Tauglich?
Hier nur ganz kurz ein paar Möglichkeiten angeschnitten:
- Falls man einen Apache Webserver benutzt, in die .htaccess einfach:
Header add X-Pavatar 'http://example.com/pfad/zum/pavatar.png'einfügen. - Wenn man die .htaccess nicht benutzen kann, hat man die möglichkeit per PHP einen Header zu senden. Dazu muss man folgenden Code in eine Datei, die ausgeführt wird, wenn man eure Homepage aufruft einfügen:
header('X-Pavatar: http://example.com/pfad/zum/pavatar.png'); - Wenn das nicht funktioniert fügt ihr eine solche Zeile in den Header eueres Templates ein:
<link rel="pavatar" href="http://example.com/pfad/zum/pavatar.png" /> - Wenn alles nicht klappt, ladet eine Datei namens pavatar.png dahin hoch, auf das ihr verweist, wenn ihr einen Link zu eurer Seite postet. Oder ihr ladet es in euren Document Root hoch.
Ich würde mich freuen, wenn ihr darüber in euren Blogs und Foren berichtet, damit die Spezifikation auch eure Plugin Programmierer erreicht, und diese Pavatare für eure Lieblinssoftware – seien es Weblogs, Foren, Gästebücher oder sonst etwas – verfügbar machen.
Und dann noch die wichtigste Frage: Was denkt ihr über die Idee Avatare dezentral verfügbar zu machen? Was haltet ihr von der Umsetzung in meiner Spezifikation?
[update:] Text an die neue spec angepasst.
Pingbacks
- kronn.de - weblog » Blog Archive » Die beste Linksammlung des Monats
- Ich will einen Pavatar!, medienrauschen
- Rü´s weblog » Alternativen zu Gravatar?
- Topic Gold rings - Public Forum
- Gravatar – Es lebt? - Jowra - Webdesign · Photo · Artwork
- Good bye, Gravatar? - blog :: weinschenker.name
- Gravatare - Schon wieder at Punctilio
Kommentare
Die Kommentare sind für diesen Eintrag geschlossen.
Felix Riesterer aus Ba-Wü schrieb am 23.10.2005
Hi Jeena!
Generell finde ich die Idee nicht schlecht, denn wenn man sich die Verlässlichkeit von gravatar.com anschaut, dann kann man nicht sonderlich zufrieden sein.
Aber bei pavatar ist anscheinend keine Möglichkeit enthalten, dass der Inhalt des Gezeigten in Klassen á la "jugendfrei", "ab 18" usw. einordbar ist (wie z.B. bei gravatar.com). Diese Möglichkeit kann wohl nur ein zentraler Dienst bieten, bei dem echte Menschen (keine Scripts!) in Handarbeit die optischen Inhalte klassifizieren.
Ansonsten ist die von Dir vorgeschlagene technische Lösung sicherlich verlässlicher und störungsfreier.
Liebe Grüße,
Felix Riesterer.
Jeena Paradies aus Varberg schrieb am 24.10.2005
Hallo Felix,
Natürlich habe ich daran gedacht, deshalb gibt es den letzten Punkt der Spezifikation: Fitting the laws:
Jeena Paradies aus Varberg schrieb am 24.10.2005
Hallo Benni,
[RFC 2616] Abschnitt 7.1 definiert, dass man beliebige Headerfelder dazuerfinden kann, die dann ggbf. ignoriert werden wenn der Empfänger sie nicht kennt.
An die Aktualisierung habe ich natürlich gedacht, siehe: Updating
Wie die Pluginautoren das machen ist ihnen überlassen. Ich persönlich würde zu jeder URL ein Pavatar speichern und da auch die Expires oder Cache-Control Daten mitspeichern. Je nach dem was der Kommentator dort angegeben hat würde ich es abrufen, oder wenn nichts angegeben wurde, das Pavatar einmal in der Woche, wie auch empfohlen, neu abrufen.
Das mit dem Timeout sollte eigentlich nicht wirklich ein Problem sein. Man kann diesen so einstellen wie man will und dann wird auch nur einmalig bei dem verzögert, der gerade kommentiert. Und der weiß dann meistens, dass seine eigene Seite down ist.
Die Sicherheit ist ein Problem der Pluginhersteller. Sie müssen ihre Software sicher machen, das kann eine Spezifikation nicht leisten.
Wieso sollte es gerade bei PNG Browser-Abschies-Möglichkeiten geben und nicht bei JPEG und GIF?
Jeena Paradies aus Varberg schrieb am 24.10.2005
Das kannst du doch in einer .htacces genau so in deinen Unterordnern machen.
Er ist stärker als <link> weil er einfach um ein vielfaches preformanter ist als eine HTML seite herunterzuladen und diese zu parsen.
Jan aus Biederbach schrieb am 24.10.2005
Das mag stimmen, aber Otto-Normal-Blogger hat vielleicht keinen Zugriff auf die .htaccess-Datei, das war der Vater des Gedanken. Ich habe mit CommentsTrack mal etwas versucht [1], das ähnliche Techniken nutzen sollte, und die Funktionalität auf Spielzeughostern zu gewährleisten war immer ein Problem.
Allerdings fällt mir auch kein sinnvolles Szenario [2] ein, in dem jemand einen Pavatar global für eine ganze Domain per header setzen sollte, wenn die Nutzer eben dieser eigene Pavatere definieren möchten - und nur dann könnte es ja zu einer Diskrepanz kommen.
Also vergiss meinen Einwand einfach - du hast schon Recht.
[1] Ich versuche weiterhin in einer abgespeckten Version und mit dem Namen CommentsTrack light ein funktionierendes Kommentartracking zu basteln.
[2] Ein nicht ganz so sinnvolles Szenario: Ein Bloghoster entscheidet sich bei allen gehosteten Blogs den Pavatar-Header auf eine Grafik mit dem Service-Logo zu setzen um damit ein wenig Werbung in den Kommentarbereichen der Blogs, die Pavatar unterstützen und in denen seine Nutzer aktiv kommentieren, zu machen.
Henryk Plötz aus Berlin schrieb am 24.10.2005
Moin,
(Vorweg: Magst du dein Englisch nicht nochmal durch einen Spellchecker jagen? Die dürfte es für Englisch genug geben. commentor -> commentator, referrs -> refers, localy -> locally, etc. Das ist so wie es ist echt schwierig zu lesen.)
Weiter: Die Anleihen an hixies Pingback-Spezifikation finde ich gut und richtig, da sie eine Implementation erleichtern. Dementgegen spricht hier aber wieder das Parsen einer robots.txt, was in dem Kontext für meinen Geschmack zu kompliziert und fehlplatziert ist. Ich nehme an, dass ist auch nur drin für den unwahrscheinlichen Fall, dass jemand schon eine Ressource namens pavatar hat, die aber nicht als persönlichen Avatar benutzen möchte? (Weil sonst könnte er sie ja einfach löschen.)
Man könnte sich a) einfach auf den Standpunkt stellen, dass das eh nicht passiert (mit dem Namen favicon.ico scheint ja auch keiner ein Problem zu haben) und den Teil über die robots.txt ersatzlos streichen. Oder b) einen anderen Weg gehen. Ich fände es zum Beispiel von der Implementationsseite einfacher, wenn definiert wäre, dass die Implementation die die Absicht hat, einen pavatar abzurufen ein bestimmtes Stichwort in ihrem User-Agent-Header erwähnt, oder (falls du annimst, dass es Leute gibt die darauf keinen Einfluss haben) einen besonderen Request-Header setzt. Auf der Seite des pavatar-Nicht-Anbieters könnte man das ziemlich einfach durch die Serverkonfiguration abdecken und solche Requests verbieten. Das hat für den Implementator kaum Zusatzaufwand und für den pavatar-Nicht-Anbieter nur geringen Aufwand. Den beiden Leute die eine Ressource namens pavatar haben wollen, ohne die zum Persönlichen Avatar zu machen kann man das schon zumuten, finde ich. (Allgemein stehe ich sogar eher auf dem Standpunkt a)
Nun schreibst du "Caching Personal Avatars saves a lot of traffic." Dem möchte ich widersprechen. Tatsächlich generiert es (zugegebenermaßen nur wenig) zusätzlichen Traffic. Denn sieh mal: Cachen tut der Browser des Besuchers eh. Mit dem Cachen auf Bloganbieterseite hat man also Verkehr zwischen Besucher und Blog-Anbieter (inkl. conditional gets) plus zwischen Blog-Anbieter und Pavatar-Anbieter. Ohne Cachen auf Bloganbieterseite hat man nur Verkehr zwischen Besucher und Pavatar-Anbieter (undzwar genausoviel wie vorher zwischen Besucher und Blog-Anbieter).
Wenn man also das Bild nicht auf dem Blogserver zwischenlagert spart man (kleine Mengen) an Traffic. Durch das Cachen sparst du nur gegenüber dem Fall Traffic, dass der Blog-Anbieter für jeden Besucher das Bild nochmal vom Original-Pavatar-Anbieter zieht. Das war aber nur ein Sonderfall, auf den du getroffen bist, als du für CK die gravatare eingegraut hast.
Zusammenfassend vorgeschlagene Änderungen: robots.txt weg, Englisch korrigieren, "cachen spart traffic" weg, dafür vorschlagen, die pavatare direkt von der Originalseite zu verlinken (und sagen dass der dortige Server gefälligst ordentliche Caching-Header senden soll, damit conditional gets etc. gehen) und explizit erlauben, dass die Pavatar-Implementation das Bild auf ihrer Seite zwischenspeichern kann, zum Beispiel wenn sie es modifizieren möchte, dann aber für ordentliches Caching und gleichzeitig für Cache-Integrität zu sorgen hat (lies mal RFC 2616, da ist ein ganzer Abschnitt darüber, wie man richtig cached).
--
Henryk Plötz
Grüße aus Berlin
Henryk Plötz aus Berlin schrieb am 24.10.2005
Moin,
Jan: Die Idee ist von hixie (oder hat der sie noch irgendwo her) und es geht ganz einfach darum, dass es für diese Autodiscovery ausreichen sollte, einen HEAD-Request auf die Ressource abzusetzen (das sollte Jeena vielleicht noch dazu schreiben) und so Verkehr und Verarbeitungszeit zu sparen. Das <link>-Element ist nur als Fallback für Leute da, die keinen ordentlichen Webspace haben.
D.h. Autodiscovery sollte so ablaufen, dass man einen HEAD-Request auf den URL macht, nach dem Header schaut, falls er nicht da ist, macht man ein GET und wendet den regex an (Jeena: Du solltest von Hixie auch die Optimierungsempfehlungen übernehmen), und wenn das nichts bringt, versucht man, eine Adresse zu raten (favicon-style).
--
Henryk Plötz
Grüße aus Berlin
Jan aus Biederbach schrieb am 24.10.2005
Ich werfe noch ein Argument pro Caching in die Runde:
Sind alle Avatare gecachet, sind sie beim Abruf der Kommentare auf jeden Fall verfügbar - dies ist nicht gewährleistet wenn die direkt von den Server der Kommentierenden geladen werden.
Jan aus Biederbach schrieb am 24.10.2005
Ach Mist, erstens kann ich nicht tippen (...wenn sie direkt von den Servern der...) und zudem steht das ganze schon im Blogpost oben.
Ich würde vorschlagen
einfach zu
zu ändern.
Damit lässt man dem Weblogbetreiber alle Möglichkeiten offen um die Avatare z.B. in Graustufen zu konvertieren und dann direkt auszuliefern. Ebenso sollte der Nutzer dann allerdings auch die Möglichkeit haben das Caching und damit die Manipulation seines Avatar zu verbieten (über passenden Header auf seinem Server).
Jeena Paradies aus Varberg schrieb am 24.10.2005
Jan, zum nichtvollen Szenario ist zu sagen, dass ein Webmaster die möglichkeit hat solche Pavatare einfach abzulehnen.
Das caching sollte einen rießen vorteil bringen und zwar, dass die Pavatare immer verfügbar sind, egal ob die Seite des Kommentators erreichbar ist oder nicht. Ansonsten hätten wir das gleiche Problem wie bei Gravatar.com jetzt. Eigentlich wollte ich da sogar must schreiben, habe mich aber von Christian überzeugen lassen, dass es Szenarien gibt (z.B. allow_url_fopen) bei denen der Server nicht auf fremde Server zugreifen kann um Dateien zu holen. Deshalb das should. Es muss auch völlig beim Webmaster liegen, ob er denn ein Pavatar verändern will oder nicht, der Kommentator muss sich damit abfinden, dass es um ins Design zu passen verändert wird. Das gleiche mit dem caching, es sollte unbedingt dem Webmaster überlassen werden wie oft er updaten will, den Empfehlungen des Kommentators zu folgen steht ihm natürlich frei.
Henryk, ja ich werde mal einen Spellchecker drüberlaufen lassen, du weißt ja gar nicht wie das aussah bevor die vier drübergegangen sind ;-).
Ich sehe ein, der Satz "Caching Personal Avatars saves a lot of traffic." wird wegkommen, weil er einfach nicht stimmt.
Zur robotx.txt, so wie es aussieht hast du recht es ist ziemlich aufwendig die robotx.txt richtig zu parsen, so dass alle Fälle abgedeckt werden. Bevor ich auf die Idee mit der robots.txt kam, habe ich überlegt, dass der, der keine Pavatare anbieten will einfach in den Header ein bestimmtes Stichwort anstatt der URL reinschreibt, so etwas wie "X-Pavatar: none" oder so, equivalent für den <link>. Dafür die robots.txt ganz weglassen. Wäre das eine gute Alternative?
Henryk Plötz aus Berlin schrieb am 24.10.2005
Moin,
Ja, das ist ok. Ich würde an der Stelle (Abschnitt 3.b, letzter Absatz) noch einmal ausdrücklich betonen, dass es sich um den absoluten URL handeln muss (damit der Implementierer da nicht noch anfangen muss, relative URLs aufzulösen; das macht keinen Spaß, kann ich dir sagen) und dann als Alternative 'none' als Schlüsselwort definieren. D.h. das href-Attribut muss entweder einen absoluten URL oder das Schlüsselwort enthalten, nichts anderes.
Frage in die Runde: Gibt es da Probleme mit automatischen Linkcheckern oder dergleichen? Alternativ würde ich vorschlagen, dass jemand sich opfert und einen echten URL zur Verfügung stellt, der dann als Angabe für "kein pavatar" verwendet wird. So ähnlich wie man bei XML-Namespaces auch URLs benutzt, ohne dass die dahinterstehenden Ressourcen aufgerufen werden. Statt 'none' würde man dann eine Adresse wie http://jeenaparadies.net/no-pavatar (das ist ausdrücklich nur ein Beispiel!) verwenden, und die Implementationen müssten dann hartkodiert diesen URL entsprechend interpretieren. Als Anforderung ist dann aber gestellt, dass der Inhaber der Adresse sich bereit erklärt und versucht, sie so lange wie möglich für diesen Zweck zu reservieren.
--
Henryk Plötz
Grüße aus Berlin
macx schrieb am 24.10.2005
Die Erreichbarkeit von gravatar.com war in letzter Zeit wirklich nicht gut. Statt aber über Alternativen nachzudenken, und diese sogar zu programmieren, wäre es doch besser, ihr wendet euch an den Entwickler und helft bei der Problembewältigung, weil Gravatar bis jetzt eigentlich ein Standard ist. Programmiert eine deutsche Version, helft ihm mit der Bereitstellung von Know How.
Das wäre in meinen Augen wesentlich sinnvoller als fünfzehn Alternativen, die ich in meinem Blog allesamt einbinden müsste, um jeden zufrieden zu stellen.
Jörg Petermann schrieb am 24.10.2005
Habe die Spezifikation glatt überlesen. Auszeit zum lesen notwendig! :))
Jeena Paradies aus Varberg schrieb am 24.10.2005
macx, Gravatar.com hat konzeptionelle Schwächen, die man nicht mit Manpower und Know How beseitigen kann. Die Zentralisierung ist in meinen Augen die größte Schwäche, und diese wird Gravatar.com nicht aufgeben.
Jörg, ich gebe zu, wenn man nur den Text hier liest, dann ist es schon sehr schweer sich vorzustellen wie das funkitionieren soll ;-)
Jeena Paradies aus Varberg schrieb am 24.10.2005
Henryk, die zweite Variante finde ich unnötig, es ist ja nicht soo schwehr auf ein Keyword zu prüfen, bevor man eine solche URL durch einen automatischen Linkchecker jagt.
macx schrieb am 24.10.2005
@Jeena
Man muss Gravatar nicht zentral halten. Denkbar wäre doch eine Option: Zental oder dezentral. Ich glaube auch nicht, dass du dort mal nachgefragt hast.
Verstehe mich bitte nicht falsch. Respekt vor deiner Arbeit und der Lösung, doch in zwei Woche ist dies die zweite Alternative zu den Gravataren. Ich bin nunmal für Standards. Solange sich der Entwickler von Gravatar nicht sperrt, und er ist für Diskussionen momentan im Blog sehr offen, sollte man versuchen, dies weiterzuentwickeln. Sperrt er sich, dann bin ich der erste, der dein System unterstützt. Im Prinzip verfolgst du exakt das Ziel, welches ich auch am sinnvollsten halte. Ich möchte nur keine fünfzehn Konkurrenzsysteme. ;-)
Jeena Paradies aus Varberg schrieb am 24.10.2005
Das was ich versuche zu entwickeln ist ein offener Standard, den jeder so nutzen kann wie er will. Gravatare sind in meinen Augen eher ein Monopol und kein Standard, und ich mag persönlich Monopole nicht so gerne.
Der Vermischung zentral, dezentral steht doch überhaupt nichts im Wege. Es liegt an den Plugin-Programmierern die zwei Systeme komfortabel zusammenzufügen. In Christian Kruses Block Implementation ist das zum Beispiel so gelöst, dass wenn jemand eine E-Mail Adresse angibt, Gravatar abgefragt wird, fallst nicht, Pavatar. Ich habe mit absicht darauf geachtet 80x80px zu nehmen, damit es da mit dem Format keine Probleme gibt.
Du siehst, die Systeme müssen nicht miteinander konkurieren, sie können sich auch sehr gut ergänzen.
Jeena Paradies aus Varberg schrieb am 24.10.2005
Henryk, in Abschnitt 3.b, letzter Absatz steht doch ausdrücklich:
Oder meinst du etwas anderes damit, wenn du sagst:
Henryk Plötz aus Berlin schrieb am 24.10.2005
Moin,
was ich meinte ist eine Textänderung hin zu sowas wie
The Personal Avatar ressource placeholder must be replaced by the absolute URL (and not a relative URL) of the Personal Avatar or the keyword none, if all Personal Avatar requests should be refused.
(also vom Sinn her, die Formulierung ist so noch nicht ganz sauber und fügt sich schlecht in deinen Textverlauf ein.)
--
Henryk Plötz
Grüße aus berlin
Jeena Paradies aus Varberg schrieb am 24.10.2005
Ah jetzt wird es deutlicher was du meintest. Ok ich habe es geändert und die neue Version mit all ihren Veränderungen hochgeladen.
Ingo aus Dieburg schrieb am 24.10.2005
Tolle Idee! Die Specs muss ich mir noch mal genauer anschauen. Ich werde dann timtab - die Blog Extension für TYPO3 - für Pavatare erweitern.
Gruß
Ingo
Jeena Paradies aus Varberg schrieb am 24.10.2005
Sehr cool dass du dich jetzt schon meldest Ingo. Vielen Dank für deine angebotene Unterstützung.
René aus Wolverhampton schrieb am 24.10.2005
Man sollte ggf. noch Einschränkungen im Dateiformat machen. Nicht, daß eines Tages die Teenagerblogger auf den Zug springen und ihre frischgeknipsten Digitalkamerabilder dann anbieten - und wir bei jeder Prüfung 2 MB durch die Leitung senden ...
Zur Update-Frage: was sprich dagegen, das Avatar stets von den Originalseiten einzubinden (also keine locale Pufferung)? Wenn der Server abschmiert, ist halt ein rotes X zu sehen - und Traffic sollte doch nicht unbedingt ein Problem sein, oder?
Es könnten nun Analysedienste anfangen, überall testweise Avatare zu verteilen - um dann das Surfverhalten der Besucher zu analysieren (aber auch die gibt es jetzt schon) - aber man hätte automatisch eine Möglichkeit des Reverse-Trackbacks bei Kommentaren, sprich: auf Basis der Referrer könnte ich eine Liste erstellen, wo ich überall kommentiert habe.
Jan aus Biederbach schrieb am 24.10.2005
Das sehe ich nicht so. Ist kein Caching aktiviert, funktioniert dann eben einer von 5 Pavataren nicht, das ist das selbe wie wenn ein Webseite des Kommentierenden offline ist. Kein Beinbruch und zu akzeptieren. Ist Caching jedoch aktiviert, dann kann das nicht passieren, der Webmaster braucht jedoch ein bisschen komplexere Scripte.
Ich verstehe nicht wieso es beim Webmaster liegen muss - wenn möglich (und in diesem Fall IST es ganz einfach möglich) sollte doch die Gewalt beim Besitzer des Avatars bleiben. Technisch ist es aufwändiger ein Caching zu fordern (should cache) als es nur zu wünschen (may cache).
Wieso überhaupt der zweite Fallback "3.c. Direct URL (the favicon.ico way)"? Pingback kommt auch ohne eine "pingback.php" aus die benutzt wird wenn kein header und kein <link> gefunden werden - dieser Punkt 3.c. scheint mir eigentlich überflüssig. Was war deine Motivation diesen Punkt überhaupt mit in die Specs zu nehmen Jeena? Warum ist es notwendig?
Sorry wenn ich das nicht kapiere, aber wäre es nicht einfacher den Header wegzulassen um "none" auszudrücken? Einen Header zu setzen nur um auszusagen dass kein Gravatar vorhanden ist / geholt werden soll gefällt mir nicht, denn das ist doch eigentlich der Standardfall.
Jeena Paradies aus Varberg schrieb am 24.10.2005
René, es gibt Einschränkungen: GIF, PNG, JPEG 80x80px. Da wird es wohl kaum zu sachffen sein ein 2MB Bild zu intergrieren, und falls doch kann man es leicht ablehnen.
Die Pavatare der Analysedienste kann man ja ganz einfach ablehnen, nicht so wie bei zentralen Systemen.
Wenn ein solcher Server abschmiert, dann gibt es eben kein rotex X, dondern es dauert ewigkeiten bis die Seite geladen ist, bzw. bis irgend ein Timeout vom Browser kommt. Wenn man da JavaScript bei onLoad nutzt ist das wirklich super lästig. Das ist eigentlich das was mich an Gravatar.com am meisten stört, zeitweise ohne die Bildchen leben ist kein Problem, aber dieses ewig hängen das nervt. Wenn alle Pavatare gecached wären würde das nicht passieren. Außerdem kommt noch der Aspekt der Überwachung hinzu. Wenn man diese Pavatare cached, kann man überwachen was auf den eigenen Seiten angezeigt wird (also keine XXX Bildchen und dergleichen). Nutzt man die remote Variante kann der Kommentator bösartige sachen auf deine Seite einschleusen. Das argument mit den komplexeren scripten kann ich so nicht hinnehmen. Das machen doch sowieso erfahrene Programmierer, die die Plugins, oder die Software selbst schreiben, das sollte doch kein Problem darstellen?
Warum sollte der Besitzer des Pavatars Gewalt über die Seite des Webmasters bekommen müssen? Dann bindet es doch niemand mehr ein, wenn es das Design zerstört und das nur weil man sich an die Vorgaben des Kommentators halten muss, welcher ja keine angepassten Pavatare für jede Seite haben will, sondern ein allgemeines.
Nicht jeder ist so versiert, dass er einen Header verschicken kann, oder HTML Quellcode bearbeiten kann. Auch diese Leute sollten unbedingt die Möglichkeit bekommen ein Pavatar nutzen zu können. Ein Bildchen hochladen schafft dagegen eigentlich fast jeder.
Wenn der Header weggelassen wird, gibt es immer noch einen zweiten und dritten unnötigen request und somit zwei 404er in den Logdateien und eine Verzögerung des Scriptes. Wenn jemand sowieso weiß dass er keine Pavatare nutzen möchte und ihn aber diese 404er in seinen Logs stören gibt er einfach einen 'X-Pavatar: none' header aus und hat seine Ruhe. Dazu ist das gedacht.
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Jan, ein should ist eine etwas stärker bindende Empfehlung. Ein may ist nur eine Grundsätzliche Erlaubnis, deshalb halte ich das should für angebracht: es _sollte_ so sein, muss aber nicht. Das Caching bietet ja einige Vorteile für den Benutzer: dank Connection: keep-alive muss nur eine TCP-Verbindung zu einem Server aufgebaut werden statt zu dreißig verschiedenen. Die Seite wird für den Benutzer einfach schneller. Der Programmierer muss ja keinen Cache einbauen, er sollte es nur tun, im Sinne des Traffics und im Sinne des Benutzers. Nein, das should ist IMHO an der Stelle richtiger als ein may.
In meiner Implementation im Cforum und im Block habe ich es übrigens so gebaut, dass der Administrator einstellen kann, ob die Avatare gecached werden sollen oder nicht.
Jan aus Biederbach schrieb am 24.10.2005
Das kann einfach das Script übernehmen. Hier kann der Webmaster dann einfach festlegen was er auf seinen Seiten haben will und was nicht.
Dann ist da was falsch programmiert. Bei Pavatar ohne Caching sollte es ja so ablaufen: Benutzer kommentiert, Script besorgt sich URL vom Pavatar und speichert diese, beim Anzeigen der Kommentare wird diese URL als Bild eingebunden - dann gibt es keine Hänger oder ähnliches sondern ein rotes X wenn der Server down ist.
Das sehe ich nicht so. Für mich muss so eine Spezifikation vor allem einfach umzusetzen sein. Deshalb auch meine Antipathie gegen irgendwelche robots.txt-Sachen, none-Header oder anderen Kram.
Wenn ein Webmaster die Avatare um jeden Preis bearbeiten möchte, dann darf er eben nur Avatare speichern bei denen der Inhaber es erlaubt. Es darf aber meiner Meinung nach nicht sein, dass man nur duch Nutzung eines Pavatars dem Webmaster die Erlaubnis geben muss damit jeglichen Schindluder zu betreiben. Denn das könnte den Nutzer dann ja vom Kommentieren abhalten.
Ich bin ja nicht generell gegen das Cachen der Avatare, es gibt dem Webmaster auf jeden Fall mehr Kontrolle. Aber als Nutzer muss ich eben auch die Möglichkeit haben das ganze zu verhindern, und zwar ohne auf meinen Kommentar mit URL-Angabe verzichten zu müssen. Also soll sich das Caching-Script an meine Wünsche halten und eben ggf. keinen Avatar einblenden.
Ich denke da an favicon.ico - die Mozillabrowser produzieren auch ständig 404er wenn die Datei niht vorhanden ist. Aber das ist meines Erachtens nach kein Problem. Der Browser erwartet hier eine Datei, wenn keine Datei da ist gibts eben einen 404er. Genau dafür ist der 404er doch da.
Okay, dann habe ich den Begriff ein wenig überbewertet.
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Jan,
Die Einfachheit der Implementation sollte aber nie die Nutzerfreundlichkeit einschränken. Den robots.txt-Kram fand ich auch extremst überflüssig, bin froh, dass ich den Teil aus den Plugins wieder streichen kann. Aber das Caching halte ich durchaus für sinnvoll.
Die Nicht-Erreichbarkeit teilt sich in mehrere Fälle:
1) Der Server war schonmal erreichbar, die Pavatar-URI ist also bekannt. In dem Fall würde sie nur noch eingeblendet werden und es gäbe ein Timeout beim Browser, irgendwann dann mal, weil der Browser die ganze Zeit versucht einen Server zu erreichen, der nicht erreichbar ist. Der Opera versucht es z. B. 20 mal, der Firefox hat AFAIR eine ähnliche Anzahl. Ein extrem nerviger Fall für den Benutzer.
2) Der Server war noch nie erreichbar, die Pavatar-URI ist also unbekannt. Das Kommentar-Script versucht, die URI zu erschließen, muss aber jedesmal auf einen TCP-Timeout (beachte: der ist nicht zu umgehen, man muss ja schliesslich unterscheiden können zwischen langsamer Verbindung und Nicht-Erreichbarkeit) abwarten (per Default sind das AFAIR 120 Sekunden). Ob der Benutzer so lange wartet? Zweifelhaft. Gegen diesen Fall kann leider nichts getan werden.
Der erste Fall jedoch ist verhinderbar – durch Caching. Ausserdem verhinderbar ist der Fall, dass die Verbindung zu dem Server, auf dem der Pavatar ist, sehr langsam ist. Das ist fast genau so nervig wie ein nicht erreichbarer Server.
Dein „rotes X“-Einwand hört sich danach an, als würdest du den IE benutzen. Keine Ahnung, wie der das handhabt, aber bei Opera und Firefox bekommt man durchaus mit, wenn Teile einer Seite nicht geladen werden können.
Das kannst du ja. Dafür gibt es den Expires- und Cache-Control-Header sowie HTTP-Statuscodes. Setze den Wert für Expires auf einen Wert <= jetzt (wobei jetzt == Zeitpunkt, zu dem der Request gemacht wird) und schon muss das Script jedesmal nachfragen. Für den Fall, dass kein Pavatar eingeblendet werden soll, ist vorgesehen, ein 403 Forbidden zu senden.
Jeena Paradies aus Varberg schrieb am 24.10.2005
Genau so ist es doch bei Gravatar, oder nicht? Dennoch hängen bei mir alle Seiten ewigkeiten, wenn der Server mal down ist und erst nal langer Zeit wird ein broken image angezeigt. Oder liegt das daran, dass eine PHP Datei angewordert wird?
Eben das wird ja hierdurch sichergestellt:
Wobei man sich da auch überlegen sollte ob da nicht lieger gleich ein 'X-Pavatar: none' versendet werden sollte wenn der referer von einer Seite kommt auf welcher man (aus welchen Gründen auch immer) seine Pavatare nicht anzeigen möchte.
Ich habe immer wieder gelesen, dass sich leute über diese von Microsoft verursachten 404er ärgern (frag mich nicht warum). Außerdem steht da ja auch wieder should, so dass es nicht zwingend notwendig ist aber sehr empfohlen wird so zu verfahren.
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Jeena,
Nein.
McShelby schrieb am 24.10.2005
Hi, ich habe bisher ein Plugin namens Comvatars für Wordpress geschrieben, dass die Funktionalität von Favicons und Gravataren verbindet. Ich könnte mir durchaus auch noch eine Unterstützung für Pavatare darin vorstellen, allerdings scheue ich das Caching.
Um intelligentes Caching zu implementieren, braucht es Zeit. In diesem Fall dann meine, solange kein anderer Pavatare für Wordpress implementiert. Und es wird ganz erheblich viel Zeit benötigen. Das alles nur um etwas Bandbreite zu sparen? Hey, wir reden von Grafiken 80x80 Pixeln mit 3kB Größe! Da ist es mir als Betreiber einer Pavatar-Seite völlig wurscht, wieviele Server kontaktiert werden müssen. Hauptsache, mein Pagelayout braucht dadurch nicht genauso lange um korrekt angezeigt zu werden. Da kann man aber mit einem HTML-Trick (Trick ist hier eigentlich schon übertrieben) drumrum kommen.
Das Caching hält mich momentan definitiv von einer Implementierung ab!
In diesem Zusammenhang fällt auch Kapitel 5 der Spec: Fitting the law: Als Betreiber einer Seite muss ich also jetzt nicht nur jeden Beitrag eines Benutzers lesen und ggf. sperren, sondern ich muss mir auch noch seinen Pavatar betrachten? Und jedes mal, wenn sich der Pavatar ändert(!) muss ich aufs neue entscheiden ob ich Beiträge des Benutzers anzeige?
D.h. wenn ein Benutzer sagt, dass sein Pavatar jeden Tag expired und ich habe davon 12000, dann habe ich aber ne ganze Menge am Tag zu tun...
Ganz ehrlich glaube ich, dass man mit einer dezentralen Lösung wie Pavatar kein Rating hinbekommt, es sei denn man refresht den Cache manuell.
Jan aus Biederbach schrieb am 24.10.2005
Jein, ich habe das der Einfachheit halber von René übernommen. Ich meinte damit allgemein ein Bild das nicht geladen werden kann.
Wieso verlangsamen die Gravatar-Einbindungen den Seitenaufbau wenn es doch nur Bilder sind? Bei mir wird immer zuerst eine Seite geladen, und dann bauen die Grafiken sich auf. Oder kapiere ich hier ein grundlegendes Problem nicht?
Fassen wir die Caching-Sache zusammen:
1. Caching ist möglich, aber nicht notwendig.
Es bietet eine Menge Vorteile, macht die Scripte aber auch komplexer da eventuelle Expire-Header etc beachtet werden müssen.
2. Caching kann vom Nutzer verboten werden.
Dadurch wird auch eine Veränderung am Avatar verboten. Der Webmaster muss dann entscheiden ob er einfach die URL direkt und ohne Veränderungen einbindet oder keinen Avatar einblendet.
Jeena Paradies aus Varberg schrieb am 24.10.2005
Genau, und erst danach wenn alle Bilder fertiggeladen sind wird das JavaScript ausgeführt, siehe Christians Erklärung Nr. 1). Und danach verschwindet erst der Ladebalken. Das ist wirklich nervig.
Nicht die Beiträge sondern das neue Pavatar. Das muss man übrigens mit Gravatar jetzt auch schon machen, da die unter Amerikanisches Recht fallen, und dieses sich vom Deutschen unterscheidet. Nicht alles was in den USA erlaubt ist, ist auch hier erlaubt. Auch wenn die Jungs schon eine sehr gute Vorauswahl bieten, entbindet das uns als Webmaster nicht davon alles zu kontrollieren.
Nein, das um das lästige hängenbleiben der Seite, falls der externe Server nicht erreichbar ist, zu unterbinden und das Pavatar dennoch schnell laden zu können. Und damit es im allgemeinen schneller geht (siehe Christians Erläuterungen zu Connection: keep-alive).
Das stimmt, das ist das größte Manko der ganzen Sache und muss noch anders gelöst werden.
Wie könnte das denn funktionieren? Jeden Pavatar einmal laden und cachen und dann nie wieder verändern, außer ein User schreibt mich an und ich refreshe seinen Pavatar von Hand?
Jan aus Biederbach schrieb am 24.10.2005
Nur weil ein Pavatar neu geholt wird muss das ja nicht heißen dass er sich geändert hat. Der "neue" Avatar kann mit der gecachten Version verglichen werden (dinfach die Inhalte beiden Dateien vergleichen) und wenn sich nichts geändert hat (99% der Fälle) direkt angezeigt werden. Falls er sich doch geändert hat kommt er eben in das Moderation-Queue.
Problematisch wird das erst wenn jemand auf die lustige Idee kommt einen dynamischen Avatar auf seinen Server zu laden...
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Jan,
Das Vergleichen kann idR eigentlich sogar wegfallen. Dafür gibt es ja conditional gets mit If-Modified-Since. :)
Jan aus Biederbach schrieb am 24.10.2005
Ach stimmt ja. Zu einfach und offensichtlich :)
Knut Karnapp aus Deutschland schrieb am 24.10.2005
Also das klingt durchaus interessant und ich werde beobachten wie sich das durchsetzt bzw. etabliert. Auf den Gravatarzug bin ich noch nicht aufgesprungen aus schon vielfach genannten Gründen, mal schauen wie sich das mit den Pavataren verhalten wird.
McShelby schrieb am 24.10.2005
Das wäre wohl die traurigste aller Lösungen aber durchaus denkbar. Aber ich will gerade noch mal einen Schritt zurück...
Nehmen wir mal an, man implementiert Pavatare ohne Rating. Was dann von der Funktionalität bleibt ist eigentlich nichts weiter als ein Favicon. Das braucht kein Mensch, denn ich sehe jetzt keine wahnsinnig neuen Features, die es rechtfertigen noch eine neue Technologie einzuführen. (Okay, das ist meine Meinung, falls ihr das nicht so seht, bin ich gerne zu Diskussionen bereit)
Ergo ist Rating ein MUSS und ich kehre von meinem geistigen Ausflug zurück. Da Rating also ein MUSS ist, bleibt immer noch zu klären wie das in einer Weise gelöst werden kann, die für den Webmaster möglichst wartungsfrei ist.
Wenn ich Webmaster bei heise.de bin und mir von sämtlichen Usern die Avatare angucken und einzeln raten muss, dann mag das zwar gut für die Arbeitsplatzstatistik sein, aber nicht für Bilanz von Heise.
Welche Möglichkeiten gibt es um Rating zu implementieren:
a) Zentral
Der Gravatar-Ansatz. Vorteil: Es funktioniert sofern man die Rating-Konditionen akzeptiert. Nachteile: Reichlich. Der zentrale Server kann ausfallen, das Rating unterliegt einem Monopol, das Rating nach amerikanischem System ist nicht unbedingt überall auf der Welt anzuwenden (wenn mal jemand damals beim Entwerfen der ASCII Tabelle soviel Weitsicht gehabt hätte...)
b) Lokal
Für das Rating der Avatare ist der Webmaster verantwortlich. Vorteil: Volle Kontrolle über die Avatare. Nachteil: Siehe oben, Administration endet im Selbstmord (mindestens in meinem) ;)
c) Netzwerk
Jetzt fange ich mal an zu spinnen und werfe mal ein paar unausgegorene Ideen in den Raum: Es gibt ein Netzwerk von Rating-Servern ähnlich einem Filesharing-Netzwerk (Nachteil: die müssen irgendwo betrieben werden). Die Implementierung fragt wie in Lösung a) einen Server, kann aber auch auf andere Server umschalten, sofern dieser keine Antwort gibt. Sofern ein Webmaster mit dem Rating eines Avatars nicht zufrieden ist, kann er zu seinem Rating-Server seine eigene Bewertung schicken. Der Rating-Server schickt die Bewertung an die anderen Server im Netzwerk.
Jetzt braucht man noch einen Algorithmus, der auf Basis von altem und Webmaster-Rating ein neues Rating erstellt.
Das Rating selber stelle ich mir übrigens nicht wie bei den Gravatars mit einer linearen Abstufung vor, sondern eher in der Art
{ <Eigenschaft>=<Wert> }*Also in der Art
. So kann jede Seite für sich selbst entscheiden, welche Eigenschaft für sie noch tragbar ist. Die Amis hätten lieber
während die konservativen Europäer dann vielleicht zu
tendieren.
Uh - verdammt langer Post geworden. Ups...
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
McShelby,
Ich glaube, ihr übertreibt das ein wenig. Ich glaube nicht, dass das so oft missbraucht werden würde. Missbrauch kommt, denke ich, immer dann, wenn auch der Inhalt des Kommentars Lösch-würdig ist. Ansonsten wird sich der Missbrauch in Grenzen halten *prophezei*
Henryk Plötz aus Berlin schrieb am 25.10.2005
Moin,
Lasst uns nochmal über einen Punkt sprechen, der bisher gar nicht erwähnt wurde (und der auch gegen Caching spricht): Sicherheit. Die Spec sollte noch um einen Absatz Security Considerations (nach dem Vorbild der RFCs) ergänzt werden. Vorschlag (noch zu erweitern/ergänzen):
--snip
A caching implementation raises some security issues that the implementor should be aware of. Any such implementation should implement a security policy as defined by the administrator that installs the implementation.
Some key points of common security policies might include:
+ Disallow any URL scheme except HTTP, HTTPS and maybe FTP for the Pavatar URL. In particular the administrator might not want to allow file:// URLs, because an attacker might then be able to set file:///etc/passwd for their Pavatar URL to retrieve a copy of that file (or any other file on the server hosting the Pavatar implementation).
+ Disallow any MIME-type except for image/* for the Pavatar image, so that an attacker can not easily use the Pavatar implementation as an anonymous proxy to retrieve arbitrary files (this may be a reason to disallow FTP, because it doesn't provide a Content-Type: header).
+ Send Via: and X-Forwarded-For: headers on all HTTP requests that were initiated in response to user interaction to clearly state who is responsible for each request. This is to prevent an attacker from using the Pavatar implementation as an anonymous proxy.
+ Disallow connections to all hosts that the server hosting the Pavatar implementation shares a (security) association with or that might grant that server special privileges based on IP address. For example this is nearly always the case for the local host or some of its aliases.
--snap
Ich bekomme bei sowas halt immer leichte Bauchschmerzen, wenn eine meiner Applikationen scheinbar in meinem Auftrag (also von meiner Adresse aus) irgendwelche Aktionen auf fremden Rechnern durchführt, ohne dass ich die Chance habe diese abzusegnen. Zum einen geht es darum, keinen anonymen Proxy anzubieten über den dann aller möglicher Schindluder vertrieben werden kann (Sektion 5 bei dir), zum anderen sollten aber auch keine neuen Sicherheitsprobleme entstehen (keine neue Iteration vom beliebten readfile($_REQUEST["url"]) in PHP). Dazu gehört zum Beispiel auch eine eingehende Prüfung, ob der URL der da grade abgerufen wird nicht vielleicht auf dem aktuellen Server liegt, weil das dann viel Spaß bringen kann. Also zum Beispiel ist es nicht völlig unüblich einige Ressourcen nur für bestimmte IP-Adressen wie 127.0.0.1 oder 192.168.0.0/16 freizugeben und das sollte man mit einer Pavatar-Implementierung nicht umgehen dürfen.
Das ist aber fast alles site-abhängig und sollte als starke Empfehlung, sich damit zu beschäftigen und seinen eigenen Weg zu finden in die Spec.
(Ach, dabei habe ich gemerkt, dass es sinnvoll wäre, in dem definitions-Teil sauber zu unterscheiden zwischen: Autor der die Implementierung schreibt, Implementierung, Administrator der die Implementierung installiert, Server auf dem die Implementierung läuft, Pavatar-an-und-für-sich. Und wo wir dabei sind: falsche Wörter in fetter Schrift tun echt weh! Es heisst zwar implementor, aber trotzdem commentator)
--
Henryk Plötz
Grüße aus Berlin
Christian Kruse aus Dortmund / NRW schrieb am 25.10.2005
Henryk, für Pavatare ist doch nur HTTP erlaubt? Zumindest war es so, als ich das letzte mal in die Spec gesehen habe.
Henryk Plötz aus Berlin schrieb am 25.10.2005
Moin,
ach Christian, nu komm mir hier doch nicht mit Fakten. ;-)
--
Henryk Plötz
Grüße aus Berlin
René aus Wolverhampton schrieb am 25.10.2005
@Format: die 80*80 Pixel sollten in die Spezifikation rein, oder?
@`rotes X´: ja, die Sache ist aus dem IE - und ich nutze ihn seit Ewigkeiten nicht mehr. Aber jeder weiß, was das `rote X´ ist. Ein nicht geladenes Bild ist definitiv kein Problem (man könnte noch über alt-Text diskutieren, width/height-Angaben sind notwendig)
was man nicht machen sollte, ist im PHP ein if(fileopen(....) einabauen - und davon anhängig das Bild darstellen ...
und allgemein: man sollte das ganze simpel halten. Es ist kein Must-Feature, es ist einfach eine nette Gäste nebenbei ...
Jeena Paradies aus Varberg schrieb am 25.10.2005
Ich weiß ja nicht wie das bei euch ist, aber bei mir hängt die Seite bis zu zwei drei Minuten bis das Timeout kommt. Und da wird der Ladebalken angezeigt und der Mauszeiger zeigt die Sanduhr. Und das hängt am nicht geladenen Bild. Das ist für mcih definitiv das größte Problem was ich mit gravatar.com habe.
macx schrieb am 25.10.2005
Hat sich eigentlich schonmal hemand Gedanken gemacht, dass hinter einer Domain mehrere Personen stecken könnten. In einer Familie beispielsweise sollte nicht nur dem Vater zustehen, die Hompage mit seinem Pavatar zu versehen. Ich denke, dass jeder Pavatar-Request mit den Namen gekoppelt sein sollte, wie auch immer das auszusehen hat.
Das wäre sogar noch sinnvoller als die Referenzierung über die eMail-Adresse, wie es Gravatar macht. Denn dies hält mich davon ab, hier bei dir Jeena meine eMail-Adresse anzugeben. Dein "mailto:" ist ein Willkommensgeschenk für Spam-Robots und ein Graus für meine Nerven beim Lesen der eMails.
Also meine Bitte: Nagelt den Pavatar nicht an die Domain selbst, denn das ist der große Nachteil von Favatar. Und Nachteile sollte euer System doch nicht bringen?!
Christian Kruse aus Dortmund / NRW schrieb am 25.10.2005
macx, ein Pavatar ist nicht an eine Domain sondern eine spezifische URI gebunden. Beispiel: Familie, Vater, Sohn und Tochter (Quoten-Frau ;-) posten Kommentare. Nun kann der Vater posten mit der URI http://example.com/vater, der Sohn mit http://example.com/sohn und die Tochter mit http://example.com/tochter. Der Pavatar hängt an der URI, nicht an einer spezifischen Domain.
Jeena Paradies aus Varberg schrieb am 25.10.2005
Das was er vorschlug sind keine Verzeichnisse, denn diese enden mit einem Slash. Was er zeigte hätten zum Beispiel ganz normale HTML Dateien sein können, die ein <link rel="pavatar" href="http://example.org/sohnens-pavatar.png"> enthalten können, oder PHP Dateien, die den entsprechenden Header senden, oder wie du schon vorschlugst den entsprechenden Header in der .htaccess spezifizieren, je nach dem auf wen zugegriffen wird.
Markus Wulftange aus Osnabrück schrieb am 25.10.2005
Die Idee des Pavaters verbindet die beiden Vorteile eines Gravatars und eines Favatars: monopolunabhängigere Avatare mit einer größeren Auflösung als typische Icon-Grafiken.
An der Spezifikation finde ich besonders gut, dass alles über HTTP-Header allein abgewickelt werden kann. Auch das Caching-Problem könnte darüber gelöst werden.
Martin schrieb am 25.10.2005
Nützlich fände ich, wenn das Skript, das die Pavatare abruft, folgende Header senden würde:
User-Agent: Pavatar-fetcher/0.1.2 (Wordpress 1.5.2)
Referer: http://example.org/weblog/trallala
Der User-Agent sollte immer mit "Pavatar-fetcher", gefolgt von einem Schrägstrich und der berücksichtigten Version der Spezifikation beginnen (damit man ggf. Requests abweisen kann, wenn eine veraltete, unbrauchbare/fehlerbehaftete Spezifikation verwendet wird) und darf dann optional noch eine nähere Beschreibung enthalten, die in Klammern zu setzen ist. Der Referer sollte eine URL enthalten, auf der kommentiert wurde (idealerweise die, auf der man zuletzt kommentiert hat). Und zwar die komplette URL und nicht nur den Root.
Ich werte gerne meine Logs aus ;-)
Jan aus Biederbach schrieb am 25.10.2005
Bringt das auch noch was wenn der Webmaster das Caching der Avatare aktiviert hat?
Christian Kruse aus Dortmund / NRW schrieb am 25.10.2005
Jan,
Nein ;)
Markus Wulftange aus Osnabrück schrieb am 26.10.2005
Ich schreibe gerade ein paar kleinen Algorithmen, die bei der Verarbeitung der Anfrage eines Pavatars hilfreich sein könnten.
Noch etwas zum Caching: Wieso wird nicht auch hier ein Header-Feld zur Entscheidung herangezogen? Wenn der Kommentator nicht möchte, dass sein Pavatar zwischengespeichert wird, soll er dies durch das „Cache-Control“-Header-Feld ausdrücken und das verarbeitunde Skript dies auf der anderen Seite entsprechend berücksichtigen.
Christian Kruse aus Dortmund / NRW schrieb am 26.10.2005
Markus,
ich weiss nicht so recht wie man es noch deutlicher ausdrücken soll. In der Spec steht doch mehrfach:
Das gesamte Caching läuft nur über die HTTP-Header.
Jan aus Biederbach schrieb am 26.10.2005
Das ist einfach unglücklich formuliert. Da sollte stehen, dass das Script das sofort macht.
Markus Wulftange aus Osnabrück schrieb am 26.10.2005
Entschuldige, Christian, die selbst Spezifikation habe ich bisher nur überflogen.
Christian Kruse aus Dortmund / NRW schrieb am 26.10.2005
Markus,
Wofür entschuldigst du dich? ;) Da gibt es nichts, was entschuldigt werden müsste.
Jeena Paradies aus Varberg schrieb am 26.10.2005
Jan, warum sollte die Implementation es, nachdem es das Pavatar heruntergeladen hat, sofort noch einmal checken und updaten? Das macht für mich irgendwie keinen Sinn. Sollte sie nicht erst warten bis es wieder Zeit ist es upzudaten?
Jan aus Biederbach schrieb am 26.10.2005
Na, ich meinte das anders. Sorry.
Es sollte klarer herausgestellt (formuliert) werden, dass das Script auch beim ersten Aufruf gleich schaut ob es das überhaupt darf, ob es die Daten dann cachen darf und wann es die Daten aktualisieren muss.
Da darf ja absolut kein Zweifel daran aufkommen wie das funktioniert, weil das sind (für mich auf jeden Fall) wichtige Punkte anhand derer ich entscheide ob ich das System gut oder schlecht finde.
Jeena Paradies aus Varberg schrieb am 26.10.2005
Ah jetzt verstehe ich. Die Formulierung führt in die irre, da man dadurch glaubt man könne sich als Implementator aussuchen wie lange »a period of time« sein soll. Ok das stimmt, ich nehme es in die Liste mit auf.
Jan aus Biederbach schrieb am 26.10.2005
Noch mehr, man könnte glauben dass man z.B. erstmal alle Avatare cachen darf und sich erst beim Update um eventuelle Header kümmern muss.
Martin schrieb am 27.10.2005
Wieso nicht? Natürlich findet kein Request statt, solange der Pavatar noch im Cache ist. Aber wenn er abgerufen wird, dann sollte doch bitte auch ein Referrer gesendet werden.
Jan aus Biederbach schrieb am 27.10.2005
Ja und welchen dann? Den vom letzten Kommentar, den vom zuletzt aktiven Kommentarthread? Da wüsste ich keine wirklich sinnvolle Antwort drauf. Ich würde da eher zur Hauptadresse tendieren... oder den Link zu einer Übersicht mit allen Kommentarthreads in denen der Nutzer teilgenommen hat - aber soviel ich weiss unterstützt das bisher keine (Weblog-)Software.
Andere Frage dir mir ein Kollege gestellt hat als ich ihm das System erklärt habe:
Der Nutzer hat schonmal einen Kommentar mit Pavatar bei mir hinterlassen. Beim Abruf wurde meinem Script mitgeteilt dass ich alle 4 Wochen nach einem neuen Avatar schauen soll. Nun kommentiert er aber nach 4 Tagen nochmal. Nehme ich nun einfach den Avatar aus dem Cache [a] oder hole ich ihn neu - wird dann der Cachingtimer wieder auf 0 gesetzt [ b] oder läuft er weiter [c]?
(Ich würde [a] anwenden.)
Jeena Paradies aus Varberg schrieb am 27.10.2005
Ich würde auch [a] nehmen. Aber die Spez. überlässt die Entscheidung dem Implementationsentwickler.
Natürlich könnte man das auch spezifizieren, aber ich glaube nicht dass man alles zu tode definieren muss damit das ganze funktioniert, oder? Sonst wird das ganze viel zu aufgebläht. Es sollen eigentlich nur Rahmenbedingungen geschaffen werden mit denen man als Implementator arbeiten kann und auf die man sich verlassen kann.
Ich sollte mal eine richtige Liste mit den angedachten Veränderungen zusammenstellen.
Martin schrieb am 28.10.2005
Wie oben schon gesagt, würde ich beim Referrer zu der URL tendieren, auf die der Nutzer zuletzt kommentiert hat. Eine Liste mit all seinen Kommentaren wäre aber auch sehr willkommen, gute Idee! Aber an sich ist das auch nicht soo wichtig, zu welchem Kommentar die URL korrespondiert, aber was mich derzeit an so mancher Favatar-Implementierung stört ist die fehlende Zuordnung zu einer Domain. Man hat nur die IP und der Reverse-DNS-Eintrag gibt meist nur Aufschluss über den Hoster, wenn überhaupt. Insofern wäre auch die URL der Hauptseite, wie du es vorschlägst, akzeptabel, den Rest kann man meist über eine domainspezifische Anfrage an eine Suchmaschine herausfinden. Allerdings bin ich so einem "Fake"-Referrer grundsätzlich etwas abgeneigt. Das mag eine Macke von mir sein, okay ;-) Aber beispielsweise funktionieren Automatismen, die den Quellcode der im Referrer angegebenen Seite zwecks Referrerspamschutz untersuchen, dann nicht mehr. Das ist zwar auch weder sicherer Schutz noch funktioniert es mit via JavaScript generierten Links o. Ä., aber ich schweife ab ... Also okay, kurz gesagt: ich würde mich auch der URL der Hauptseite zufrieden geben ;-)
CottonIJoe aus bei München, Deutschland schrieb am 31.10.2005
Ich bin Pavatar-ready (hoffentlich) ;)
bed aus Braunschweig schrieb am 01.11.2005
Ich habe mich bemüht, die Nutzerseite zu kapieren.
Habe ich recht, wenn ich sage, dass das Pavatar anhand der eingegebenen URL identifiziert wird?
Bei mir auf Zockertown.de z.B. schreiben ja mehrere (mehr oder weniger) Autoren. Wenn die aber alle ein verschiedenes Pavatar haben sollen, so bräuchte ich für jeden Autor ein Verzeichnis, damit ich es via .htaccess bereitstellen kann?
Oder mit Direct URL z.b.
?
Jeena Paradies aus Varberg schrieb am 01.11.2005
Jeder Autor bräuchte eine eigene Seite, nicht unbedingt ein Verzeichnis. Wir nehmen an der User heißt Klaus. Dann braucht er eine HTML Seite, z.B. http://zockertorwn.de/Klaus.html Wenn man diese Seite aufruft gibst du entweder einen header mit X-Pavatar: http://example.de/mein_Pavatar-Bildchen-von-Klaus.jpg aus, oder die Seite wird heruntergeladen und im Header wird nach <link rel="pavatar" href="http://example.de/mein_Pavatar-Bildchen-von-Klaus.jpg" /> gesucht und dann diese URL als Pavatar-URL genommen.
Alternativ (falls man header nicht setzen kann, und den Quelltext der HTML Seite nicht bearbeiten kann) kann man ein Verzeichniss für jeden erstellen und dort rein das Pavatar mit dem Namen pavatar reintun. Wird auf eine Datei in diesem Verzeichnis verwiesen, oder nur auf das Verzeichnis selbst guckt die Implementation nach, ob es dort eine Datei mit dem Namen Pavatar gibt. Falls ja wird das als Pavatar genommen, falls nein wird im document root (bei dir also http://zockertown.de/pavatar) geschaut.
Triendl David aus Österreich schrieb am 05.11.2005
Ich werde mal schauen, ob ich schaffe, das in mein Blog einzubauen...
Jeena Paradies aus Varberg schrieb am 12.11.2005
Ich habe für Pavatar ein neues Projekt in meinem Bugtracker eröffnet und werde jetzt anfangen alle Verbesserungsvorschläge dort zu sammeln. Das gute ist, dort kann man dann zu jedem "Bug" einzeln diskutieren ohne dass es wie hier so ein Durcheinander gibt.
Ihr seit auch herzlich eingeladen dort Vorschläge und Bugs einzutragen: http://jeenaparadies.net/bugs/index.php?project=2
David Triendl aus Österreich schrieb am 12.11.2005
Wenn ich Probleme bei der Implentation habe, kann ich dann auch dort nachfragen?? Ich würde eher ein kleines Forum vorschlagen...
Jeena Paradies aus Varberg schrieb am 13.11.2005
Gar keine so dumme Idee mit dem Forum.
David Triendl aus Österreich schrieb am 14.11.2005
Wie wäre es mit einem auf Selbstkontrolle basiernden Rating, also dass vielleicht http://pavatar.com/pavatar.jpg#G als URL angibt, für einen Avatar der "jugendfrei" ist (siehe Rating bei gravatar.com). Die URL bliebe damit die gleiche, aber es liese sich das Rating besser kontrollieren...
Jeena Paradies aus Varberg schrieb am 14.11.2005
Welche erleichterung würde das bringen? Man muss ja dann immernoch jeden Pavatar einzeln nachprüfen.
David Triendl aus Österreich schrieb am 14.11.2005
Ja schon, aber man kann schon vorher alle unerwünschten Pavatare aussortieren, wenn diese vom Besitzer gekennzeichnet wurden. Obwohl ob sich das lohnt, ist eine andere Frage. Ich schätze mal, weniger als 0,1 % der Gravatar-User haben einen Gravatar, der nicht in G oder PG drinsteht...
fwolf schrieb am 24.11.2005
nur mal kurz zum "rating übers netzwerk" - schon mal was von Fido.Net gehört? ich wei0, viele 'kiddies' haben keinen blassen schimmer (mehr), dass es vor dem internet-hype schon 'online gehen' gab, nur lokaler und vielleicht nicht so ganz 'klicki-bunti' wie das heutzutage der fall ist. nannte sich im deutschen 'mailbox' - IMHO eine krasse fehlübersetzung, da extrem leicht mit 'voicebox' oder 'email mailbox' zu verwechseln - im englischen 'bbs' und dort gab es verschiedene sog. Netze, welche täglich einmal 'gepollt' wurden, d.h. Daten komprimiert zwischen verschiedenen Mailbox-Systemen hin- und hergeschaufelt worden.
Angeblich war früher das Maus-Net sehr bekannt, was ich allerdings NIE bestätigt finden konnte - ich war immer Fidorianer, kann sogar noch meine alte Adresse auswendig (2:2480/3504.19) und bin über Z-Netz und Maus höchst selten gestolpert.
Mein Vorschlag: Ich hatte immer mal wieder die Idee, einen austausch zwischen forensystemen über ein diesen netzen ähnlich geartetes system zu etablieren - selbiges könnte man ansatzweise sicherlich auch zwecks Pavatar aufbauen.
Ein Vorschlag wäre der Arbeitstitel "Pavatar-Net", weitere Ideen: Polling einmal am Tag, komprimiertes Versenden von Daten, entweder dezentrales, verteiltes computing oder aber mit zentralisierter Struktur a la Fidonet (zur erklärung: meine alte adresse fidonet-adresse (2:2480/3504.19) besteht aus folgenden Teilen:
2 - steht für Zone 2, d.h. Europa
2480 - steht für den regionalen verteiler nummer 2480 - hub genannt
3504 - meine damalige mailbox (CCS-Base) - node genannt
19 - sogenannter point - einzelner nutzer (nr. 19 in diesem fall), p2p/bittorrent wäre auch was, aber schwieriger umzusetzen bzw. zu implementieren (nicht alles auf einmal), sehr einfaches protokoll, etc.
cu, w0lf.