David 'TheRaven' Chisnall
theraven at sucs.org
Tue May 6 17:52:58 UTC 2003
Just another minor point:
If we do manage discourage client developers from implementing
experimental features, then you have less (well, actually no) testing
before something becomes a standard, so problems are less likely to be
Having an experimental namespace allows this.
On the other hand, we need to use something like disco to allow clients
to determine which experimental features other clients support, and
attempt to use them with other clients (e.g. not send Avatar data to a
Hmm. That may have been 2 points. Oh well, there are only 3 sorts of
Justin Kirby wrote:
>On Tue, 2003-05-06 at 13:05, Rachel Blackman wrote:
>>But this IMNSHO ruins the entire point of Jabber, which is open standards
>>and client interoperability.
>no it doesn't. jeps are EXPIREMENTAL!!! which means impl at your own
>risk. It only has the *potential* to become a standard. So how does
>changing something that should not have any production code break
>> 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...
>If you do that, then you deserve to have a broken client ;)
>Standards-JIG mailing list
>Standards-JIG at jabber.org
More information about the Standards