[standards-jig] Avatars

Rachel Blackman rcb at ceruleanstudios.com
Tue May 6 17:05:17 UTC 2003

> I can appreciate that client authors want to do things for there users,
> but I think we need to spell out the "correct" process by which you can
> use an experimental JEP.  What it will probably boil down to is, using a
> namespace significant to your client like:  gabber:x:avatar or
> http://gabber.jabberstudio.org/protocol/avatar, and a willingness to
> move to the standardized versions when they appear.

But this IMNSHO ruins the entire point of Jabber, which is open standards
and client interoperability.  If I as a client author wanted to implement
avatars the way you suggest, and so did others...now, in order to have
avatars work between our clients, I have to handle incoming namespaces of,
say, 'http://gabber.jabberstudio.org/protocol/avatar' and
'rhymbox:x:avatar' and 'jajc:x:avatar' and so on.

I grant you it discourages people from implementing the protocol, but it
also seems more likely to fractionalize the Jabber community; if I don't do
the work of finding all the clients that support avatars (or taking the
lazy route of just checking for :x:avatar or /avatar on the end of a
namespace), you only see avatars from other people using the same client...

> As to why the JEP was published, that's the correct process for a JEP. 
> You publish a version you want discussed, it is labelled appropiately
> (experimental), and discussion begins.  At a certain point it is final
> called, and sent to the council.  Then it moves on from there.  I don't
> see anything wrong with how the JEP was treated.  Heck, back then it was
> even faster to get voted on, and I'm pretty sure the JEP was voted away
> rather quickly after introduction.  So, it probably boils down to a
> labelling issue, and the helpful hints I mentioned above for
> implementors.

I understand that; it was a devil's advocate position, since you were
saying it was bad for the client authors to have implemented it.  My point
was that you could also say it was bad for the protocol to propose a
desired extension and then leave it up in the list for two years as
'deferred' without a functional replacement. :)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030506/9bbcd640/attachment.sig>

More information about the Standards mailing list