[jdev] Jabber Certification Program

[Rachel Blackman]

>> The thing is, there are all these very cool Jabber featuresets out 
>> there, but lots of them are not necessarily supported.  Nor (other 
>> than peer pressure) is there much incentive for people to implement 
>> certain things.  I can look at Jabber and go 'wow, pubsub is a cool 
>> backend system, Stream Initiation will let me do a lot of really cool 
>> things down the line' and be excited, but your average IM user (for 
>> instance, my mother or father) will look at Jabber and go 'why can't 
>> I set a nice little picture like under MSN?  And why can't I use bold 
>> in my messages?' and so on.
>
> To me *that* sounds like you're saying: there are all kinds of cool 
> specifications out there, but noone is using them.

I think I phrased this badly, so I'll try again in a moment to 
summarize my intent in this proposal.  However, I would submit that you 
are getting rather sidetracked by making this a debate over motives 
rather than benefits or drawbacks to this; regardless of /my/ intent in 
putting this proposal out there, surely you have your own opinions on 
what benefits or drawbacks this proposal has?  That was in large part 
what I was interested in hearing from others. ;)

Okay.  Trying to summarize my intent again.

Right now, there are lots of features out there.  To use XHTML as an 
example (or file transfer in the older days), because of the fact there 
is an attitude (rightly or wrongly) that implementation of experimental 
JEPs should be discouraged, sometimes we see custom extensions to 
clients as interim solutions.  (Witness various client-specific mutant 
HTML-marked-up message implementations.)

A certification program would:

1) Encourage standardization and interoperability, as anything 
'certified' would be pretty much guaranteed to interoperate probably 
with the other certifications.

2) Indicate (through 'recommended' features in each year's 
certification definition) features which are not yet required for 
certification but which will likely be required in the following year.  
(Including experimental JEPs.)

3) 1 and 2 together; instead of spending effort making an 'interim 
solution' specific to your client while there is no clear 
non-experimental solution, all the client authors striving for 
certification and interested in a feature would thus have an incentive 
to concentrate their efforts on making a standard.  The JEP process is 
supposed to be driven not only by the Council but by the community, and 
this would drive community action.  Let's say someone wants a webcam 
solution in their client, but the only webcam JEP is Experimental and 
unfinished, not in a state where it can yet be implemented; if that 
webcam JEP is on the 'recommend' list for certification, then instead 
of going 'well, that JEP will not be Draft for a long time so I will 
just make my own client-specific solution for now,' the developer has 
an incentive to really push the JEP process forward, flesh out the JEP 
and so on.  Someone wanting certification is not required to implement 
the webcam JEP or participate in moving it forward, but might want to 
watch it if it is a potential for, say, the next year's 'Jabber Media 
Client' certification or whatever.

(This is not to say I think webcams will ever be a requirement on any 
certification, but I needed an example to pull from thin air.)

> If we had this certification proces I don't think the number of 
> clients who would have implemented those obsolete ways would be that 
> much greater either. The very reason those ways are declared obsolete 
> is cause a large part of the developers do not agree with the methods 
> used. Nor would we have more clients who adopted the new ways (because 
> these are limited by others factors, the JEPs are still new, server 
> infrastructure is still missing (eg. IBB)), nor would it have sped up 
> the creation of new JEPs (having an installed base of the 
> old-now-obsolete experimental JEP that is also "certified" won't do 
> much good there!).

To uses your example, let's say that the old avatar specification was 
'certified' one year, and then it's found to be bad, and it's replaced. 
  Now you put the new avatar specification into the certification; those 
who want to keep their 'certified' status implement this.  Those who do 
not implement it do not get certification again.

I would say the problem is twofold.

First, there is not a direct incentive to work on pushing JEPs forward 
-- implementing them, experimenting, finding their flaws and strengths 
and thus revising them so they mature -- and in fact (as has been seen 
in this thread), there are developers who actively /discourage/ people 
from implementing Experimental status JEPs, meaning they sit and 
languish.

Secondly, there is no direct incentive to update to more current JEPs 
(save for interoperability) when ones go away.  With existing clients 
doing the old-style deferred avatar method, I will bet you that many 
will not consider it a priority to move to the newer avatar 
specification when it gets finished, which does hinder the adoption of 
newer protocol extensions.  In fact, this state of affairs encourages 
adoption of OLDER methods; if a new client author comes in, and wants 
to do avatars, and finds only one other client does the new pubsub 
method but five or six use the old method, I suspect the author in 
question is going to implement the old method as well.

> Such a certification could have great benifits. Even if it won't speed 
> things up much, it would certainly enable the Jabber community to grow 
> as a whole (eg. look at the recent flare up in the PubSub discussion). 
> I would be carefull with what you call certification though, writing a 
> profile for clients and what they should implement is one thing, 
> checking wether a client entirely adheres to that specification *that* 
> could be called certification, but that is a difficult and costly 
> proces.

Hence why you need the Certification Board to manage this, hence the 
original proposal.  And yes, it isn't that it could be "called" 
certification, that /is/ what was intended as certification. ;)

> Just having the specifications for the different profiles (as agreed 
> by the major participants with an intrest of forming these specs) and 
> some organizing for interop. testing could still get you a lot of the 
> benefits! (As Stephen Pendleton suggested, real certification might 
> become an intresting commercial opportunity)

Interoperability testing and standardized featuresets is a lot of the 
motive behind this, but my experience with other projects in the past 
is that something like a 'Certified' badge (and some kind of benefit to 
go with it) would drive the standardization and interoperability better 
than just saying 'hey, let's make it all work together.'  You catch 
more flies with honey than debate, or something like that, to mangle a 
metaphor.

	--Rachel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://www.jabber.org/jdev/attachments/20040618/59290c49/attachment-0002.pgp>