Vorstellung: Personal Avatar (aka Pavatar)

[Jeena Paradies]

Hallo,

Ich möchte auch hier meine Spezifikation vorstellen: Personal Avatar (aka Pavatar)

Avatare sind kleine Bildchen, die oft in Boards, und Foren benutzt werden um die Wiedererkennung der Kommentatoren zu erhöhen. In solchen Fällen muss das Bild auf den Server des Forums hochgeladen werden und wird angezeigt sobald man einen Kommentar absetzt. Bei Weblogs hat sich der Zentrale dienst http://gravatar.com durchgesetzt, welcher Zentral diese Bilder verwaltet, was aber leider viele Nachteile mit sich zieht.

Mit meiner Spezifikation möchte ich den Betreibern von Seiten, die Kommentare erlauben die möglichkeit geben solche Avatare global einheitlich zu nutzen ohne, dass jeder für seine eigene Seite ein eigenes Süppchen kocht, oder auf einen Zentralen Dienst zurückgreifen muss.

Nähere Informationen gibt es in meinem Weblog: http://jeenaparadies.net/weblog/2005/oct/pavatar

Christian Kruse hat sich auch die Mühe gemacht für das cforum Pavatare verfügbar zu machen. Ich weiß dass viele hier gegen solche Entwicklungen sind -- das sieht man auch daran, dass graphische smilies im cforum möglich sind aber hier nicht einmal per userconf dazuschaltbar sind -- aber vielleicht könnte man per userconf Pavatare hier verfügbar machen. Man könnte sie zum Beispiel per default ausgeschaltet lassen und nur die, die sie wirklich haben möchten können sie sich selbst dazuschalten :-).

Über Meinungen und Kommentare würde ich mich sehr freuen.

Grüße
Jeena Paradies

[Ashura]

Hallo Jeena.

Avatare sind kleine Bildchen, die oft in Boards, und Foren benutzt werden um die Wiedererkennung der Kommentatoren zu erhöhen. In solchen Fällen muss das Bild auf den Server des Forums hochgeladen werden und wird angezeigt sobald man einen Kommentar absetzt.

Hierzu habe ich eine Frage: Ein solcher Pavatar wird also nur erkannt, wenn ich in dem jeweiligen Forum / Board / Blog im jeweiligen „Homepage“-Formularfeld die URL angegeben habe, unter der die Pavatar-Grafik zu finden ist?

Einen schönen Montag noch.

Gruß, Ashura

[Tim Tepaße]

Hallo Ashura,

Hierzu habe ich eine Frage: Ein solcher Pavatar wird also nur erkannt, wenn ich in dem jeweiligen Forum / Board / Blog im jeweiligen „Homepage“-Formularfeld die URL angegeben habe, unter der die Pavatar-Grafik zu finden ist?

Die Absicht des Ganzen ist es, von einer im Forum/Blog/Whatever angegebenen URL (meistens wahrscheinlich Homepage) auf eine andere URL, nämlich die des Pavatars zu kommen. Deswegen die Kaskade von HTTP Headern über ein link-Element bis hin zur doofen IE-Favicon-Methode, damit der Poster es so einfach wie möglich hat und eben nicht ständig die URL seines Pavatars herauskramen muss. Also: Nein, in das Homepage Formularfeld gehört nur die Homepage rein.

Tim

[Sven Rautenberg]

Moin!

Hierzu habe ich eine Frage: Ein solcher Pavatar wird also nur erkannt, wenn ich in dem jeweiligen Forum / Board / Blog im jeweiligen „Homepage“-Formularfeld die URL angegeben habe, unter der die Pavatar-Grafik zu finden ist?

Nein. Die Idee ist, standardmäßige Positionen für Informationen vorzuschlagen, an denen ein "interessierter Server" nachsehen könnte, ob ein Pavatar vorhanden ist:

1. Er fragt die angegebene URL ab und erhält im HTTP-Header eine Zeile "X-Pavatar" mit der Bild-URL.
2. Er fragt die URL ab und erhält die Pavatar-URL im HTML-Text (Metatag).
3. Er fragt http://www.example.org/angegebene/url/seite/PAVATAR ab.
4. Er fragt http://www.example.org/PAVATAR ab.

Mit robots.txt (warum auch immer) gehts auch irgendwie.

Das Englisch des WD ist allerdings teilweise grausam (oder greysome?), und ein paar sachliche Fehler sind auch noch drin versteckt.

- Sven Rautenberg

[Ashura]

Hallo Sven.

Nein. Die Idee ist, standardmäßige Positionen für Informationen vorzuschlagen, an denen ein "interessierter Server" nachsehen könnte, ob ein Pavatar vorhanden ist:

1. Er fragt die angegebene URL ab und erhält im HTTP-Header eine Zeile "X-Pavatar" mit der Bild-URL.

Welche URL? Woher kommt diese?

Einen schönen Montag noch.

Gruß, Ashura

[Jeena Paradies]

Hallo,

Welche URL? Woher kommt diese?

Wie Tim schon schrieb, die URL der Homepage (bei dir also http://noctus.net), da es dieses Feld fast immer gibt und die Leute ihre HP gerne reinschreiben.

Grüße
Jeena Paradies

[Ashura]

Hallo Jeena.

Welche URL? Woher kommt diese?
Wie Tim schon schrieb, die URL der Homepage (bei dir also http://noctus.net), da es dieses Feld fast immer gibt und die Leute ihre HP gerne reinschreiben.

Also doch genau nach dem Prinzip, welches ich hier schon schrieb.

Danke, nun verstehe ich das Prinzip.

Einen schönen Montag noch.

Gruß, Ashura

[Jeena Paradies]

Hallo,

Mit robots.txt (warum auch immer) gehts auch irgendwie.

Nein, das stimmt so nicht, damit sollte man als Kommentator verbieten können, dass die Resource pavatar überhaupt abgefragt wird. So wie es aussieht wird das aber wegen zu hoher preformance einbußen gestrichen.

Das Englisch des WD ist allerdings teilweise grausam (oder greysome?),

Das ist schon eine Milion mal besser als es am Anfang war ;-) Ich bräuchte da wohl jemanden, der gutes Spezifikationsenglisch schreiben kann und das berichtigen würde, ich selbst schaffe das nicht. Freiwillige vor! ;-)

und ein paar sachliche Fehler sind auch noch drin versteckt.

Ich wäre dir sehr verbunden, wenn du sie mir aufzeigen würdest, damit ich sie beseitigen kann.

Grüße
Jeena Paradies

[wahsaga]

hi,

Mit meiner Spezifikation möchte ich den Betreibern von Seiten, die Kommentare erlauben die möglichkeit geben solche Avatare global einheitlich zu nutzen ohne, dass jeder für seine eigene Seite ein eigenes Süppchen kocht,

Und deshalb geht man so etwas an, in dem man ein eigenes Süppchen namens "Pavatar" kocht?

(Btw: den Namen finde ich absolut, entschuldige, dämlich. Klingt nach Pavian-Avatar.)

Mal zu den einzelnen Punkten, die du (v.a.) in deinem Blog angeführt hast:

Der Webmaster kann selbst entscheiden welche Pavatare auf seiner Seite angezeigt werden

Ja, aber die Möglichkeit des Ratings "expliziter" Avatare wie bei gravatar.com fehlt ihm hier völlig.
Das hast du mit

The webmaster should not forget to check for every single Personal Avatar if it fits the law of his country. The implementation programmer should implement assistance for the webmaster.

recht schnell abgebügelt - reicht mir aber eigentlich nicht.
Bei gravatar.com macht jemand das Rating für mich, ich muss nur noch angeben welchen Level ich einsetzen möchte, um keine xxx/Gore/sonstwas-Bildchen auf meiner Seite platziert zu bekommen.
OK, bei einem neuen Kommentar, den ich persönlich freischalte, könnte ich das als Blogger auch noch selber checken - oder will ich überhaupt jedesmal moderieren müssen?
Dann kommt noch dein "caching"-Ansatz hinzu, bei dem das System regelmässig checken soll ob ein Update des Avatars vorliegt, oder der User das caching sogar unterbinden können soll ... also bleibt mir nur, ständig wieder zu kontrollieren, dass mir niemand Mist unterschiebt.

Der Kommentator kann selbst entscheiden wo seine Pavatare nicht angezeigt werden sollen

Das kann ich mit gravatar.com auch heute schon: Ich gebe beim kommentieren einfach keine oder eine andere als meine für den Gravatar genutzte Mailadresse an.

Durch conditional gets (GET-Requests mit If-Modified-Since oder If-None-Match) wird viel Traffic gespart

Och nö, erst mal erzeugst du doch zusätzlichen - in dem du meine angegebene Seite anfragst, um dann an diversen Orten nach einem Pavia^H^Hatar zu suchen.
Für dein Caching wirst du sogar vermutlich(?) zukünftig noch weitere Anfragen an meine Seite stellen, weil ich irgendwann/-wo mal bei dir kommentiert habe.
Also ein weiterer "Dienst", der meint, nur weil ich irgendwo eine Homepage-Adresse angegeben habe, müsste er dort nach irgendwelchen Sachen suchen, die dort vorhanden sein _könnten_.
In dem Fall hätte ich in einem Weblog, welches dies nutzt also zumindest gerne die Möglichkeit, eine "Don't bother me with Pavatar"-Checkbox anzukreuzen, damit sich dein Crawler nicht auf die sowohl für dich als auch für mich sinnlose Suche nach einem von mir gar nicht vorgehaltenen Pavatar macht. Ohne dies würde ich den Dienst als Belästigung einstufen - und mit eigentlich auch, weil ich ja wieder ein weiteres Formularelement mehr ausfüllen muss, wenn ich bloss kommentieren möchte.

Mein Fazit: Ja, gravatar.com mag seine Nachteile haben, und nach Alternativen zu suchen ist OK. Nachteile hat deine Initiative im derzeitigen, mir noch zu unausgegorenen Zustand aber auch, und noch nicht genügend Vorteile, dass ich sie für gut befinden könnte.

gruß,
wahsaga

[Jeena Paradies]

Hallo,

Und deshalb geht man so etwas an, in dem man ein eigenes Süppchen namens "Pavatar" kocht?

Irgendwie muss man das ja angehen.

(Btw: den Namen finde ich absolut, entschuldige, dämlich. Klingt nach Pavian-Avatar.)

Macht nichts ;-)

Ja, aber die Möglichkeit des Ratings "expliziter" Avatare wie bei gravatar.com fehlt ihm hier völlig.
[...]
Bei gravatar.com macht jemand das Rating für mich, ich muss nur noch angeben welchen Level ich einsetzen möchte, um keine xxx/Gore/sonstwas-Bildchen auf meiner Seite platziert zu bekommen.

Gravatar.com arbeitet nach Amerikanischem Recht. Du bist also, wenn du das einsetzt immer noch genau so wie bei Pavatar verpflichtet dir jedes Bildchen anzugucken und für gut oder schlecht zu befinden, da sich das Amerikanische Recht nicht mit dem Deutschen absolut deckt. Aber natürlich machen die schon eine sehr gute Vorauswahl.

OK, bei einem neuen Kommentar, den ich persönlich freischalte, könnte ich das als Blogger auch noch selber checken - oder will ich überhaupt jedesmal moderieren müssen?

Wenn du nicht moderieren möchtest, setzt du das einfach nicht ein, sondern nutzt weiterhin den guten Gravatar.com Dienst ein.

Dann kommt noch dein "caching"-Ansatz hinzu, bei dem das System regelmässig checken soll ob ein Update des Avatars vorliegt, oder der User das caching sogar unterbinden können soll ... also bleibt mir nur, ständig wieder zu kontrollieren, dass mir niemand Mist unterschiebt.

Wie gesagt, das musst du bei gravatar.com heutzutage auch schon, zumindest wenn du nicht in den USA lebst.

Das kann ich mit gravatar.com auch heute schon: Ich gebe beim kommentieren einfach keine oder eine andere als meine für den Gravatar genutzte Mailadresse an.

außer irgendjemand anderes gibt deine Adresse dort an.

Och nö, erst mal erzeugst du doch zusätzlichen - in dem du meine angegebene Seite anfragst, um dann an diversen Orten nach einem Pavia^H^Hatar zu suchen.

Wie schon in der Spec steht ist sie noch nciht ganz ausgereift. Ich habe den robots.txt Ansatz gestrichen und durch ein keyword im Header ersetzt. Damit kann man denke ich die Robots besser davon abhalten zu viel Traffic zu erzeugen.

Für dein Caching wirst du sogar vermutlich(?) zukünftig noch weitere Anfragen an meine Seite stellen, weil ich irgendwann/-wo mal bei dir kommentiert habe.

Ja.

Also ein weiterer "Dienst", der meint, nur weil ich irgendwo eine Homepage-Adresse angegeben habe, müsste er dort nach irgendwelchen Sachen suchen, die dort vorhanden sein _könnten_.

Das macht Microsoft und heutzutage eigentlich jeder andere Browser auch. Anscheinend stört es die Leute nicht, denn es gibt bis heute keine Möglichkeit den 404er beim fehlenden favicon.ico zu verhindern.

In dem Fall hätte ich in einem Weblog, welches dies nutzt also zumindest gerne die Möglichkeit, eine "Don't bother me with Pavatar"-Checkbox anzukreuzen, damit sich dein Crawler nicht auf die sowohl für dich als auch für mich sinnlose Suche nach einem von mir gar nicht vorgehaltenen Pavatar macht. Ohne dies würde ich den Dienst als Belästigung einstufen - und mit eigentlich auch, weil ich ja wieder ein weiteres Formularelement mehr ausfüllen muss, wenn ich bloss kommentieren möchte.

Jup, klar. Also genau so eine Belästigung wie favicon.ico, damit kann ich leben ;-)

Mein Fazit: Ja, gravatar.com mag seine Nachteile haben, und nach Alternativen zu suchen ist OK. Nachteile hat deine Initiative im derzeitigen, mir noch zu unausgegorenen Zustand aber auch, und noch nicht genügend Vorteile, dass ich sie für gut befinden könnte.

Ich arbeite daran.

Grüße
Jeena Paradies

[Christian Kruse]

你好 wahsaga,

Mit meiner Spezifikation möchte ich den Betreibern von Seiten, die
Kommentare erlauben die möglichkeit geben solche Avatare global
einheitlich zu nutzen ohne, dass jeder für seine eigene Seite ein
eigenes Süppchen kocht,

Und deshalb geht man so etwas an, in dem man ein eigenes Süppchen
namens "Pavatar" kocht?

Ein „eigenes Süppchen“ wäre eine proprietäre Lösung. Dies jedoch ist eine
offen beschriebene Lösung, die den Anspruch erhebt zu einem akzeptierten
Standard zu werden. Da kann man wohl kaum von einem „eigenen Süppchen“
reden.

再见,
 克里斯蒂安

[Daniel Thoma]

Hallo Jeena,

Der Ansatz basiert also darauf, auf Grund einer URL (der, der Homepage) eine Menge Magie zu betreiben und Information irgendwo rauszuziehen, wo sie nicht hingehört. (Was hat ein Bild, das ich irgendwo zu einem Kommentar hinzufügen will, mit meiner Homepage zu tun?)
Abgesehen davon entfällt damit die Möglichkeit ein Bild aber keine Homepage anzugeben z.B. wenn man das Bild irgendwo unterstellt, ohne eine Homepage zu haben.
Vor allen Dingen scheint mir der Aufwand, der getrieben wird, um diese Bild-URL zu finden unverhältnismäßig. Man könnte ja auch einfach noch ein weiteres Formularfeld angeben. Das ist wesentlich einfacher zu implementieren, das ganze Cachingtheater kann man genau so betreiben und es ist auch Anwenderfreundlicher für die meisten Anwender.
Natürlich muss man jedes mal zwei URLs angeben, aber erstens nimmt einem das der Browser ab, wenn die Formularfelder gleich heißen (hier könnte man evtl etwas rumnormieren), und zweitens ist das etwas, was jeder mit etwas Weberfahrung versteht. Irgend welche Header, Linktags usw. auf seiner Homepage zu setzen ist nicht intuitiv. Da muss man schon diese Spezifikation kennen.

Das Ziel dieser Aktion scheint ja zu sein, den Aufwand, Kommentarformulare auszufüllen, zu verringern.
Da könnte man z.B. einen Standard für die Beschreibung aller Profildaten austüfteln, sodass man, anstatt ein Formular auszufüllen, einfach eine Datei angeben kann, die all diese Information enthält.

Oder man geht dieses Problem gleich noch allgemeiner an und bastelt eine Standard um Formulare mit Semantik zu versehen, sodass Browser die besser automatisch ausfüllen können. Der Ansatz hat natürlich den Nachteil, dass das die Browser implementieren müssen ;-)

Grüße

Daniel

[wahsaga]

hi,

Der Ansatz basiert also darauf, auf Grund einer URL (der, der Homepage) eine Menge Magie zu betreiben und Information irgendwo rauszuziehen, wo sie nicht hingehört. (Was hat ein Bild, das ich irgendwo zu einem Kommentar hinzufügen will, mit meiner Homepage zu tun?)

Interessanter Punkt.

Das Ziel dieser Aktion scheint ja zu sein, den Aufwand, Kommentarformulare auszufüllen, zu verringern.
Da könnte man z.B. einen Standard für die Beschreibung aller Profildaten austüfteln, sodass man, anstatt ein Formular auszufüllen, einfach eine Datei angeben kann, die all diese Information enthält.

Ja, vielleicht wäre eine Identitäts-Plattform á la TypeKey der bessere Ort, um soetwas anzubringen - da könnte man gleich alle beim Kommentieren interessanten Daten an einem Ort ablegen (lassen), und das abspeichernde Script holt sich dann die Infos von dort - z.b. auch die, welchen Avatar(-URL) man benutzen möchte.
Aber auch hier gilt wieder: Noch ein weiterer Dienst dieser Art wäre wieder ein "eigenes Süppchen", welches die Landschaft nicht übersichtlicher macht, sondern im Gegenteil ihr einen weiteren Punkt hinzufügt, den ich sowohl als Benutzer als auch als (Blog-)Seitenbetreiber berücksichtigen müsste.

Oder man geht dieses Problem gleich noch allgemeiner an und bastelt eine Standard um Formulare mit Semantik zu versehen, sodass Browser die besser automatisch ausfüllen können. Der Ansatz hat natürlich den Nachteil, dass das die Browser implementieren müssen ;-)

Und den weiteren Nachteil, dass es damit den Kommentarspammern noch leichter gemacht wird, automatisiert zu kommentieren - die haben sich ja derzeit schon vor allem auf die weitverbreiteten "Standard-Blogsysteme" eingeschossen, wo sie den Formularaufbau genau kennen.

gruß,
wahsaga

[Christoph Zurnieden]

Hi,

Ich möchte auch hier meine Spezifikation vorstellen: Personal Avatar (aka Pavatar)

Aha. Und ich habe mich schon die ganze Zeit gefragt, was das genau werden soll, mich aber nie getraut zu fragen ;-)

Sieht insgesamt ganz gut durchdacht aus, auf Anhieb nichts Falsches gefunden. Das Diskussionswuerdige moegen andere diskutieren ;-)

Ich setze hier mal ein paar Vorschlaege hin (es ist einiges redundant und auch nicht immer eindeutig), ich hoffe ich bin nicht zu spaet und alles ist schon laengst perfekt in Form, Farbe und Schnitt :-)

1. Introduction

The Personal Avatar system is a way to use personalized small graphics to make commentators more recognizable through all sorts of websites where commentators leave comments. Commentators are able to host their Personal Avatars themselves and the implementation MUST support the commentators ability to restrict access to their Personal Avatar. The publisher of the Personal Avatar SHOULD be able to edit and cache the Personal Avatar. The publisher MUST be able to refuse a  Personal Avatar.

1.a. Definitions
Commentator
Commentator is the one who leaves a comment, posts, annotations or simmilar on a publishers page and is the possessor of the Personal Avatar. The commentator and the publisher MAY be the same.

Commentors Website
A commentors website MUST be a valid HTTP URL according to [RFC 1738], which the commentor has specified as his website.

Personal Avatar
A Personal Avatar is a picture stored on the commentor's website conforming to the Personal Avatar Conformance Requirements described in 2.

Publisher
The publisher provides the service for the commentator to act. The publisher and the commentator MAY be the same.

The Personal Avatar implementation (short: implementation)
This is the implementation running the publishers's service dealing the Personal Avatars.

Now
Now referrs to the time the HTTP request is finished.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

1.b. Technical Details

The implementation MUST use HTTP ([RFC 1945], [RFC 2616]) to test for the availability of a Personal Avatar at the URL specified by the commentator. In case of success, it SHOULD download, save and serve it localy but MAY also referr to the originating URL of the Personal Avatar.

An implementation MUST be able to use the HTPP caching mechanisms.

2. Personal Avatar Conformance Requirements
2.a. Technical Definition

A valid Personal Avatar MUST be a 80x80 pixel sized image in GIF ([GIF89a]), PNG ([PNG]) or JPEG ([ISO/IEC IS 10918-1], [ISO/IEC IS 14495-1], [ISO/IEC IS 15444-1]) format and MUST NOT exceed the size of 102400 Bit (twice the size of an uncompressed 80x80pixel big picture with 8-bit color depth).

A valid Personal Avatar MUST be publicly accessible through a valid HTTP URL ([RFC 1738]). This URL MUST be used to reference the Personal Avatar (see Autodiscovery).

The Personal Avatar MUST have the correct Content-Type header (e.g. with help of Apaches MultiViews). The commentator MAY use HTTP Cache-Control and/or Expires headers.

2.b. Refusing Personal Avatar requests

The commentator MAY restrict access to the Personal Avatar. The commentator MUST act accordingly to HTTP, e.g. SHOULD response with a 403 HTTP status code, if access is denied.
It is RECOMMENDED to use the key word "none" of the HTTP-Header "X-Pavatar" as described in 3.a to refuse the delivery of the Personal Avatar completly.

3. Autodiscovery

The URL of the Personal Avatar MUST be offered by the commentator in one or more of the following ways to the publisher, the use of 3.a. and 3.b. is RECOMMENDED. The publisher MUST accept all three ways.

3.a. HTTP Header

If choosed a reference to a Personal Avatar MUST be returned with a X-Pavatar HTTP header, for example:

X-Pavatar: http://example.com/my/directory/my-own_pavatar.png

The value of the X-Pavatar header MUST be the absolute URL of the Personal Avatar or the keyword "none".

The server response MUST NOT include more than one X-Pavatar

3.b. Link element

If choosed an HTML or XHTML Personal Avatar enabled page MUST contain a <link> element. It MUST have one of the following forms:

HTML
<link rel="pavatar" href="URL">
XHTML
<link rel="pavatar" href="URL" />

The URL in the "href" attribute MUST be a valid and absolute HTTP URL according to [RFC 1738] or the keyword "none".

3.c. Direct URL

If choosed there MUST be a file named "pavatar" on the commentators server.
The URL for this file MUST conform to the following form. The EBNF keywords used here are similar to the ones used in [RFC 1738].

puri = "http://" hostport *[ "/" hsegment ] "/pavatar"

Example in pseudocode:
1 IF the last hsegmet ends with a slash: GOTO 3
2 Remove the first hsegment
3 Append "pavatar" to the result
4 IF success (i.e. a 2xx answer to an HEAD request) EXIT(SUCCESS)
5 ELSE remove all hsegments
6 Append "pavatar" to the result
7 IF success (i.e. a 2xx answer to an HEAD request) EXIT(SUCCESS)
8 EXIT(FAILURE)

3.d. Precedence
The HTTP Header(3.a.) method MUST have the highest precedence, the Direct URL(3.c) method the lowest.

4. Dealing with Personal Avatars

The implementation SHOULD ensure to use as little traffic as possible to deal with Personal Avatars (e.g., use conditional get HTTP headers like If-Modified-Since).

5. Support of Conformance to Arbitrary Rules

The implementation MUST include an automatic denial-of-publish mechanism if the pavatar is unknown to the system. It SHOULD include a notification mechanism in case of an automatic denial-of-publish.

so short

Christoph Zurnieden

[Jeena Paradies]

Hallo,

Danke für deine Ideen, aber vor allem dein Punt 5 könnte uns wirklich ein gutes Stück weiterbringen.

5. Support of Conformance to Arbitrary Rules
   The implementation MUST include an automatic denial-of-publish mechanism if the pavatar is unknown to the system. It SHOULD include a notification mechanism in case of an automatic denial-of-publish.

Ich habe das mal als Kommentar zusammengefasst und gepostet.

Grüße
Jeena Paradies

[Christoph Zurnieden]

Hi,

Danke für deine Ideen, aber

Jaja, das hab ich mir schon gedacht: da quaelt man sich stundenlang, und dann bleibt da doch nix uebrig. Da haette ich ja genausogut weiterhin ... Daeumchen drehen und dem Backupsystem beim backuppen zuschauen koennen ;-)

Aber Scherz beiseite: ich hoffe es ist zumindest die Richtung klar geworden, wie das mit so einem RFC funktioniert. Mehr als eine grobe Skizze konnte ich in der kurzen Zeit aber leider nicht liefern.

vor allem dein Punt 5 könnte uns wirklich ein gutes Stück weiterbringen.

Ist ja immer wieder nett, wenn man feststellt doch nicht gaenzlich unnuetz zu sein ;-)

5. Support of Conformance to Arbitrary Rules
   The implementation MUST include an automatic denial-of-publish mechanism if the pavatar is unknown to the system. It SHOULD include a notification mechanism in case of an automatic denial-of-publish.

Falls der Grund fuer meine Formulierung unklar sein sollte: das Erste ist aus Sicherheitsgruenden (deshalb auch ein MUST), das Zweite dient zwar eigentlich mehr der Bequemlichkeit, macht aber ohne keinen grossen Sinn (deshalb ein SHOULD anstatt eines MAY).

Ich habe das mal als Kommentar zusammengefasst und gepostet.

Soll ich Dir verraten, warum ich in diesem _Forum_ gepostet habe und nicht in Deinem _Board_? Nein, nicht wirklich ein Scherz, ich komme mit Boards nicht sonderlich gut zurecht, uebersehe da gerne mal eine Antwort. Bin nunmal ein alter Sack, da klappt's nicht mehr so ;-)

so short

Christoph Zurnieden

[Götz]

Hallo Jeena!

[...] Personal Avatar (aka Pavatar)

eigentlich keine schlechte Idee, stellt sich nur die Frage, ob sich das auch durchsetzen wird.
Bisher gibt es ja schon Gravatare und Favatare, die beide mehr oder weniger weit verbreitet sind. Favatare haben gegenüber Gravataren die gleichen Vorteile wie Pavatare, nur daß sie eben kleiner sind. Den Vorteil von Favataren gegenüber Pavataren sehe ich einfach darin, daß viele Leute sowieso schon ein Favicon haben und nichts machen müssen, als ihre Homepage anzugeben, was die meisten, die eine haben, sowieso tun.

Ob es also unbedingt "notwendig" oder sinnvoll ist noch ein drittes Konzept in den Raum zu stellen kann und will ich nicht beurteilen, aber eine brauchbare Idee ist es und ich werd mein Gravatar mal demnächst auch als Pavatar verfügbar machen. Wir werden ja sehen, wieviele die Spezifikation implementieren und wieviele diese Implementierung dann benutzen werden.

MfG
Götz

[Sven Rautenberg]

Moin!

eigentlich keine schlechte Idee, stellt sich nur die Frage, ob sich das auch durchsetzen wird.

Das ist eigentlich doch genau die Frage.

Mir gefällt an der Idee nicht, dass sie nicht berücksichtigt, was passiert, wenn zwar ganz viele Systeme den Pavatar unterstützen, aber kaum jemand von den Nutzern.

Hat ein Webseiteninhaber keine Ahnung von Pavataren und gibt in einem entsprechenden Blog/Forum/whatever einfach nur seine Homepage an, kriegt er als Reaktion darauf auf seinem Webspace direkt
1. einen HEAD-Request, um den HTTP-Header auszulesen.
Den gibts nicht, also
2. einen GET-Request auf die gesamte Homepage, um den MetaLink auszulesen.
Den gibts auch nicht, als
3. einen GET-Request auf Homepageadresse+"Pavatar".
Wird mit 404 beantwortet, also als letztes
4. einen Get-Request auf Domain+"Pavatar"
den gibts auch nicht.

Das Problem ist einfach: Diesen "gibts nicht"-Zustand kann sich die Pavatar-Implementation ja schlecht merken, denn falls derjenige irgendwann mal tatsächlich einen Pavatar einbindet, will er den ja auch genutzt sehen.

Mit anderen Worten: Jemand, der in einem Blog oder Forum viel schreibt, kriegt viele sinnlose Hits auf seinen Webspace, pro Posting eine Serie von vier Stück, davon unter anderem einen Abruf des kompletten Quellcodes der angegebenen Seite (mit 10 bis 100 KB Daten) sowie zwei 404-Fehler (mit Glück ohne customized errorpage, mit Pech ebenfalls mit einigen Datenmengen).

Beim Gravatar hingegen wird der Webspace des Posters nicht weiter behelligt. Da ist Gravatar.com verantwortlich und schuld, wenn die, die es benutzen, ihr Bild nicht sehen, alle anderen aber haben nicht darunter zu leiden (wobei ich natürlich zugeben muß, dass die "Leiden" sehr unterschiedlich bewertet werden können).

Bisher gibt es ja schon Gravatare und Favatare, die beide mehr oder weniger weit verbreitet sind. Favatare haben gegenüber Gravataren die gleichen Vorteile wie Pavatare, nur daß sie eben kleiner sind. Den Vorteil von Favataren gegenüber Pavataren sehe ich einfach darin, daß viele Leute sowieso schon ein Favicon haben und nichts machen müssen, als ihre Homepage anzugeben, was die meisten, die eine haben, sowieso tun.

Favicons kann man ja durchaus in unterschiedlichen Auflösungen innerhalb der gleichen Datei erstellen: 16x16, 32x32 und 48x48 gehen. Ist natürlich dann irgendwann nicht mehr "klein", aber bietet für die, die es mögen, sicher hinreichend Platz, sich auszutoben.

Ich kann als persönliche Meinung nur kundtun, dass ich bezogen auf das SELF-Forum gegen ein solches Feature bin. Wer's benötigt, hat die vorausgefüllte Grafik-URL-Angabe zur Verfügung.

- Sven Rautenberg

[Tim Tepaße]

Hallo Sven,

Ich kann als persönliche Meinung nur kundtun, dass ich bezogen auf das SELF-Forum gegen ein solches Feature bin.

So wie es aussieht, wird das wohl im besten CForums-Stil, Entscheidungen auf den Nutzer zu verlagern, konfigurierbar sein, per default an oder aus und dieses in der Userconf überschreibar. Als Avatar-Abstinenzler wäre mir eine vollkommene Nicht-Nutzung von flt_pavatar, bei aller Liebe möchte ich nicht andauernd eine Dose Öl ins Gesicht gehalten bekommen. ;)

Wer's benötigt, hat die vorausgefüllte Grafik-URL-Angabe zur Verfügung.

Oder die Signatur, man munkelt in kommenden Versionen des CForums wird die Grafik-URL wegen berechtigter Überflüssigkeit rausfliegen.

Tim

[Jeena Paradies]

Hallo,

Mit anderen Worten: Jemand, der in einem Blog oder Forum viel schreibt, kriegt viele sinnlose Hits auf seinen Webspace, pro Posting eine Serie von vier Stück, davon unter anderem einen Abruf des kompletten Quellcodes der angegebenen Seite (mit 10 bis 100 KB Daten) sowie zwei 404-Fehler (mit Glück ohne customized errorpage, mit Pech ebenfalls mit einigen Datenmengen).

Die Implementation kann sich ja für eine gewisse Zeit merken dass es dort kein Pavatar gibt. Dann muss sie nicht bei jedem Post nachgucken. Eine Woche halte ich für angebracht.

Bei Favicons stört es irgendwie niemanden, warum nicht (da müsste nach deiner Theorie auch jedes mal eine Errorpage mit einigen Datenmengen kommen)? Da gibt es gar keine Möglichkeit diese Requests abzustellen und es wird wirklich bei _jedem_ Seitenaufruf abgerufen. Bei Pavataren muss man "nur" einen X-Pavatar: none Header in seine httpd.conf oder wo auch immer reintun, wenn es einen wirklich stören sollte und es wird "nur" abgerufen wenn jemand irgendwo kommentiert hat, und das nicht einmal bei jedem kommentar, sondern einmal in der Woche oder so.

Grüße
Jeena Paradies

[Jeena Paradies]

Hallo,

davon unter anderem einen Abruf des kompletten Quellcodes der angegebenen Seite (mit 10 bis 100 KB Daten)

Ich sollte vielleicht wie hixie darauf hinweisen, dass wenn es kein <link> element im header gibt nicht weiter gesucht werden muss. Also müsste man nur bis </header> herunterladen. Aber kann man das einfach so wärend des ladens herausfinden, dass da ein </header> kam?

Grüße
Jeena Paradies

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Aber kann man das einfach so wärend des ladens herausfinden, dass da ein </header> kam?

Selbstverständlich. Es ist auch völlig legal, dann das Laden zu stoppen und die Verbindung zu schließen.

Gruß
Alexander Brock

[at]

Hallo.

Ob es also unbedingt "notwendig" oder sinnvoll ist noch ein drittes Konzept in den Raum zu stellen kann und will ich nicht beurteilen, aber eine brauchbare Idee ist es und ich werd mein Gravatar mal demnächst auch als Pavatar verfügbar machen.

Mist, wieviele Techniken muss man denn noch erfinden, um deine Grafik endlich loszuwerden. Da wird schon eine Sau nach der anderen durchs Dorf getrieben und immer wieder höre ich ein "Bin schon da!". Nein wirklich, so macht das keinen Spaß.
MfG, at

[Siechfred]

Tag at.

Da wird schon eine Sau nach der anderen durchs Dorf getrieben und immer wieder höre ich ein "Bin schon da!".

Waren das nicht eher Hase und Igel?

Nein wirklich, so macht das keinen Spaß.

Das will ich meinen :-)

Siechfred

[at]

Hallo.

Da wird schon eine Sau nach der anderen durchs Dorf getrieben und immer wieder höre ich ein "Bin schon da!".

Waren das nicht eher Hase und Igel?

Meinst du, die veranschaulichen die Aussage zu den vorgestellten Konzepten ebenso gut? Dann hätte es wohl zumindest ein iGel sein müssen.
MfG, at

[Sven Rautenberg]

Moin!

Ich möchte auch hier meine Spezifikation vorstellen: Personal Avatar (aka Pavatar)

Mir fällt gerade ein recht simpler, vermutlich zu simpler Vorschlag ein, wie man die Nachteile (auch wenn sie gering erscheinen) der bisherigen Gravatar/Pavatar/Favatar-Technik umgehen und trotzdem eine gewisse Flexibilität bzw. Benutzerfreundlichkeit erreichen könnte.

Die Magie der bisherigen Ansätze liegt ja darin, dass ein Poster nur seine Mailadresse bzw. seine Homepage angibt, und das System sich auf automagische Weise passend dazu ein Avatar-Bildchen heraussucht.

Ansatz 1: Ein zentraler Dienst verwaltet registrierte User und ordnet den aus ihrer Mailadresse oder URL gebildeten MD5-Summen ein Avatar-Bild zu.
Nachteil: Fällt der zentrale Service aus, gibt es keine Bilder - und abgesehen davon wäre er auch schlecht kommerziell zu finanzieren, da die Bilder ja kaum Werbung enthalten könnten. Abgesehen davon sammelt dieser Dienst in irgendeiner Form personenbezogene Daten, URLs, Mailadressen (bzw. könnte es zumindest tun), was auch keinem wirklich gefallen kann.

Ansatz 2: Man setzt einfach ein Favicon auf seiner Homepage ein, welches sich relativ zur Adressangabe finden läßt.
Nachteil: Ist recht winzig, muß u.U. noch formatkonvertiert werden für Icon-unfähige Browser, und hat zwangsläufig Konkurrenz zu normalen Favicons.

Ansatz 3: Pavatare.

Alle drei Ansätze gehen aber davon aus, dass man aus Angaben, die der Benutzer freiwillig macht, irgendeine Metainformation ermitteln kann, um zusätzlich die Bildinformation herauszufinden - ein Vorgang, der zwangsläufig mit erfolglosen Versuchen endet, und zwar unglücklicherweise genau dann, wenn die Mehrheit der Nichtnutzer des Systems postet.

Die bessere Lösung wäre also ein System, bei dem (mit Ausnahme von absichtlichem Ins-Leere-rennen-lassen) eigentlich immer eine Erfolgsgarantie besteht, weil die tatsächlich vom Poster gegebenen Informationen exakt eine Ressource referenzieren, welche die ganzen automagischen Effekte steuern kann.

Mit anderen Worten: Wenn der Poster ohnehin die Mailadresse oder die URL seiner Homepage einzutippen in der Lage ist (Vielposter werden dafür Browserunterstützung zum Vorausfüllen haben), dann kann er genausogut auch die URL einer XML-Datei eintippen, welche weitere, explizite Angaben zu Meta-Informationen über seine Person macht, also beispielsweise:

  
<personal>  
  <url type="homepage">http://www.example.org</url>  
  <email>[e-mail]</email>  
  <url type="avatar">http://www.example.org/horrorpic.png</url>  
  <textdata type="name">Hägar, der Schreckliche</textdata>  
  <textdata type="signature">Ich komm' wieder - keine Frage!</textdata>  
</personal>  

Eine Implementation hätte also lediglich diese Metadaten-XML auszulesen und könnte im weiteren Postingvorgang alle angegebenen (und standardisierten) Informationen verwurschteln. Es würde also u.U. genügen, nur noch diese XML-Datei zu referenzieren, und sich um das Ausfüllen aller restlichen Felder inklusive Namen, Mail, Homepage, Alter, sexuelle Vorlieben etc. keine Gedanken mehr machen zu müssen.

Wer unterschiedliche Profile nutzen möchte, wäre natürlich in der Lage, je Posting-Ort eigene XML-Dateien anzulegen.

In diesem Zusammenhang erinnere ich ein Projekt, in dem Bekanntschafts- und Verwandtschaftsgrade durch eine XML-Verlinkungsaktion verdeutlicht wurden. Damit man das Rad nun nicht neu erfindet, wäre eine diesbezügliche Recherche sicherlich nicht verkehrt, um herauszufinden, ob das dort definierte Format die Avatar-Aufgabe grundsätzlich auch lösen könnte.

Abgesehen davon wäre eine Dokumentation der Bekannschaftsverhältnisse natürlich auch sehr "blogosphere-like" - zumindest für den Teil der Bevölkerung, der derartige Informationen für interessierte Kreise öffentlich zur Verfügung stellen möchte.

PS: Ich mache mir da persönlich nichts vor - auch wenn ich selbst auf derartige Features verzichten würde - bei Google findet man mich sowieso, und das auf Platz 1.

- Sven Rautenberg

[Tim Tepaße]

Hallo Sven,

In diesem Zusammenhang erinnere ich ein Projekt, in dem Bekanntschafts- und Verwandtschaftsgrade durch eine XML-Verlinkungsaktion verdeutlicht wurden.

Du meinst FOAF (Spezifikation)?

Damit man das Rad nun nicht neu erfindet, wäre eine diesbezügliche Recherche sicherlich nicht verkehrt, um herauszufinden, ob das dort definierte Format die Avatar-Aufgabe grundsätzlich auch lösen könnte.

Im Prinzip ja. FOAF mit RDF wird ja inzwischen weniger für die Dokumentation von Beziehungen als für Metadaten über einen selbst genutzt. Im Prinzip könnte man durchaus eines der Elemente foaf:img (in klein foaf:thumbnail) oder eventuell foaf:logo verwenden. Oder wenn das nicht ausreicht, definiert man sich sein eigenen Elemente:

<?xml version="1.0"?>  
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
         xmlns:foaf="http://xmlns.com/foaf/0.1/"  
         xmlns:avatar="http://example.org/avatar"  
         xmlns:dc="http://purl.org/dc/elements/1.1/"  
         xmlns:cc="http://web.resource.org/cc/">  
...  
<avatar:avatar>  
  <avatar:ressource rdf:resource="http://krawulske.example.org/~erna/avatar.svg"/>  
  <dc:format rdf:datatype="http://purl.org/dc/terms/IMT">image/svg+xml</dc:format>  
  <avatar:rating>FSK18</avatar:rating>  
  <cc:license rdf:resource="http://creativecommons.org/licenses/by/2.0/de/"/>  
  <avatar:expires>2005-12-31T23:59+01:00</avatar:expires>  
</avatar:avatar>  
...  
</rdf:RDF>

Oder man definiert natürlich gleich einen Namensraum „posting“ mit entsprechenden Elementen, die alles mitteilen, was eine Software über einen Poster wissen könnte, wenn einem die FOAF-Elemente nicht ausreichen oder man Abweichung von deren Daten haben will.

Ein paar Probleme dabei: Die Syntax der XML-Serialisierung von RDF, natürlich. Nicht jeder wird damit umgehen können. Mal abgesehen davon, dass es nicht nur eine  kanonische XML-Serialisierung eines RDF-Graphen gibt. D.h. streng genommen müsste man eigentlich einen (langsamen) RDF-Parser nutzen, statt eines halbwegs flotten Text- oder XML-Parsers. Mal ganz abgesehen davon, dass Sören-Kevin, Erna Krawulskes Großneffe, der ihr alles einrichtet, zwar HTML kann, aber von XML, XML mit Namensräumen oder gar RDF/XML noch nichts gehört hat. Wie so viele. Natürlich, es gibt Tools, mit denen man sich inzwischen FOAF-Profile zusammenklicken kann, das hilft schon etwas. Allerdings könnte diese Information in jedem beliebigen RDF-Graphen stehen - und diese werden in der XML-Serialisierung sehr sehr schnell komplex. Man gucke sich nur molilys RDF-Metadaten an - und die generiert er nur aus den marginalen Informationen, die selbst HTML Quelltext stehen.

Das Problem ist einfach der Mangel an Einfachheit. Selbst für RDF/FOAF Autodiscovery braucht man schonmal ein valides, wohlgeformtes (X)HTML-Dokument, damit man mit seinem SGML/XML oder Tag Soup Parser die Angabe <link rel="meta" type="application/rdf+xml" title="FOAF" href="http://krawulske.example.com/~erna/foaf.rdf" /> rausfischen kann. Dazu kommt noch das Parsen des RDF/XML-Graphens.

Ich habe damals Jeena vor alles deswegen zur Übernahme des Pingback Autodiscovery Algorithmus geraten, weil es einfach und in Rechenzeit preiswerter ist, entweder den HTTP Header oder mittels Regulärem Ausdruck das link-Element rauszuholen als wild in der Gegend rumzuparsen. Und vor allem, weil er vor genau demselben Problem stand. Und natürlich weil sein Problem genau das gleiche war.

Bei einer ständigen Angabe eines RDF oder FOAF Metadatendatei entfällt das natürlich, auch wenn man es im Prinzip dazu spezifizieren könnte, um die Leute nicht mit einem Formularfeld mit dem kryptischen Namen „FOAF“ zu verwirren. Bliebe höchstens das Problem der XML-Serialisierung des RDF-Graphen. Bei einer begrenzten Anwendung wäre da ein eigener XML-Dialekt oder noch besser ein Flatfile einfacher zu erstellen und einfach und performanter zu parsen. Ich würde das vorziehen.

Tim

[Gunnar Bittersmann]

Man gucke sich nur molilys RDF-Metadaten an

Hey,
Wusste gar nicht, dass außer mir noch jemand hier eine FOAF-Datei hat. Da kann ich in meiner ja mal foaf:knows erweitern. Noch jemand?

Bei einer begrenzten Anwendung wäre da ein eigener XML-Dialekt oder noch besser ein Flatfile einfacher zu erstellen und einfach und performanter zu parsen.

Man kann ja RDF (somit auch FOAF) auch in der N3-Notation angeben.

Live long and prosper,
Gunnar

[Tim Tepaße]

Hallo Gunnar,

Wusste gar nicht, dass außer mir noch jemand hier eine FOAF-Datei hat. Da kann ich in meiner ja mal foaf:knows erweitern. Noch jemand?

Ich hatte mal einen komplexeren RDF-Graphen mit integrierten FOAF-Informationen über mich, derzeit aber nicht. Ich melde mich dann, wenn sich das wieder ändert. ;)

Eine Anmerkung zu Deinem RDF/XML-Dokument:

Du nutzt Entities, wahrscheinlich um Dir Schreibarbeit zu sparen. Nicht-validierende Parser wie z.B. Browser lesen aber nicht die DTD, können also Entities nicht auflösen. Safari beschwert sich folgerichtig:

(Ist natürlich der XML-Parser, auch wenn Safari anscheinend heimlich diverse FOAF-Elemente zu beachten scheint.)

Ich denke, nicht alles, was RDF parst, ist auch ein validierender XML-Parser, Du solltest eventuell die URIs ausschreiben oder die Abkürzungen gleich in RDF/XML ausdrücken, zum Beispiel mit xml:base oder - aber da weiß ich nicht, ob das möglich ist - gleich mit im RDF-Dokument definierten fragment identifiern.

Man kann ja RDF (somit auch FOAF) auch in der N3-Notation angeben.

Auch in N3 kann man die komplex verknüpften Graphen ausdrücken, die erstmal nach den gewünschten Informationen durchgegangen werden müssen. Dagegen hat man bei der Avatar-Geschichte ja eigentlich nur eine lässige property:value Beziehung.

Tim

[molily]

Hallo,

Du nutzt Entities, wahrscheinlich um Dir Schreibarbeit zu sparen. Nicht-validierende Parser wie z.B. Browser lesen aber nicht die DTD, können also Entities nicht auflösen. Safari beschwert sich folgerichtig:

Ob das kein Fehler von Safari ist?
Meines Wissens gilt das nur für externe DTDs. Konqueror, Opera und Firefox haben auch keine validierenden Parser, verarbeiten aber die Entity-Deklarationen.
Bei anderen generischen XML-Parsern (libxml2) hatte ich auch im nicht-validierenden Modus nie Probleme mit auf diese Weise deklarierten Entitys.

Mathias

[Tim Tepaße]

Hallo Mathias,

Ob das kein Fehler von Safari ist?
Meines Wissens gilt das nur für externe DTDs. Konqueror, Opera und Firefox haben auch keine validierenden Parser, verarbeiten aber die Entity-Deklarationen.

Tatsache, wenn man die Tabelle im XML-Standard durchgeht, ist für in der internen DTD deklarieren Entities ein Einfügen required. Safari verhält sich also falsch. Ich hab mal bei WebKit einen Bug hinzugefügt. Danke für den Hinweis.

Tim

[Tim Tepaße]

Hallo Tim,

Und vor allem, weil er vor genau demselben Problem stand. Und natürlich weil sein Problem genau das gleiche war.

Ich würde sogar sagen*: Er stand vor derselben Problemstellung.

Tim