RSS Feed
abonnieren.
Suche
Wunschzettel
Weblogeinträge
ReferenzenPersonal Avatar (aka Pavatar) 23. October 2005 um 23:21 Uhr / Webdesign
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
Jeena Paradies aus Varberg schrieb am 24.10.2005
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
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
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
Jeena Paradies aus Varberg schrieb am 24.10.2005
Henryk Plötz aus Berlin schrieb am 24.10.2005
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 Plötz aus Berlin schrieb am 24.10.2005
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
Jan aus Biederbach schrieb am 24.10.2005
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
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Jeena Paradies aus Varberg schrieb am 24.10.2005
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
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
Jeena Paradies aus Varberg schrieb am 24.10.2005
Jan aus Biederbach schrieb am 24.10.2005
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
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
Christian Kruse aus Dortmund / NRW schrieb am 24.10.2005
Henryk Plötz aus Berlin schrieb am 25.10.2005
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
Christian Kruse aus Dortmund / NRW schrieb am 25.10.2005
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
Jan aus Biederbach schrieb am 26.10.2005
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
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
Jeena Paradies aus Varberg schrieb am 27.10.2005
Martin schrieb am 28.10.2005
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
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
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