[jdev] Jabber Certification Program

[Tijl Houtbeckers]

On Thu, 17 Jun 2004 20:04:27 -0400, Rachel Blackman  
<rcb at ceruleanstudios.com> wrote:

> I shouldn't really define certification as something you 'lose'; it'd be  
> something you have to strive to /gain/ each year.

Ofcourse that sounds fair enough!

Let me quote you on what started this thread:

> 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.

My question is: how do you think certification will help with that?
We all know some of those specs you mention will one day be a final  
standard, but some others will probably go from experimental to dereffered  
and some will change heavily before becoming draft and final. Do you  
predict that client authors will wait till there the certification  
guidelines are known, and then implement these JEPs? Or do you think they  
will start implementing JEPs in the hope they will be part of the  
certification? Or another possibility I am missing?

However *this* has a different sound to it;

> If you don't want to make changes to your client, that's fine.  You  
> don't suffer anything, you just don't get a new little badge with a new  
> year on it, and you don't get in the next year's list of certified  
> clients.  Meanwhile, someone who wants to use Jabber and goes to the  
> list of certified clients knows that the features on one client that are  
> part of the certification (such as, say, file transfer) /will/ work with  
> the other certified clients on the list.  So if I'm on Windows, and I  
> have a friend on MacOS X, I can point them at a MacOS X Jabber client on  
> the certified list, pick a Windows client myself, and know that the file  
> transfer between them will work because both are certified.

To me this sounds like: if we have a certification for clients it will  
help our end user pick clients that work together. And who would not agree  
with that? Perhaps you think that having a framework for compatibility  
will also increase the rate of adoption for features. You could be right,  
which would validate the piece of text I quoted from the beginning of the  
thread. I don't *think* it will matter a great deal, but I admit I'd be  
lieing if I said I am sure you are wrong on that.

If your driving force is compatibility though, you should really focus on  
*that*. After all, if you fail on that all of the attractions it brings  
along to users and developers (including the potential speed up in feature  
adoption) will fade away with it. Is it still a good idea then to bring  
experimental JEPs into this process?

You were right on the mark opening this thread that what matters to users  
is not JEPs but features. However the process through which these features  
evolve often involves not on but many JEPs and JEP revisions steered by a  
whole bunch of different factors; technical reviews, the energy put into  
them by their respective authors, compromises, politics, etc. To "certify"  
something when it's in the middle of that process..? I don't think you  
should expect (or encourage!) widespread "certified" implementation and  
usage before that process has ended, and the feature has "emerged",  
accompanied by fairly stable JEPs (which usually means there's some form  
of implementation ready too).

Maybe this is at the core of your worries; the process for those features  
to emerge through the JEP process can be agonizingly slow. And having  
certifications can speed this up! All this really accomplishes is that we  
have a simular process parralell to the JEP proces. We'd have "certified"  
clients using avatars, we'd have certified clients publishing their music  
info and with filetransfers. Because yes, those clients excist today, for  
example avatars can be found in quite a few (they just don't have the  
certified sticker)! They just do this in ways we've declared to obsolete  
(in this case through presence instead of pubsub, through HTTP or DTCP  
instead of Bytestreams, etc.). 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!).

If your worry truly is that the emergence of features through the JEP  
process is slow (and I think you wouldn't be the only one), I think the  
only solution for *that* would be try and improve that process.  
Suggestions and discussion on this subject have been done before ofcourse.

But if you *do* choose to wait for features to mature it greatly  
simplifies the process of picking which ones should be put in the  
different profiles of certification (basic client, advanced client, etc.).  
It's been suggested that one person should manage those profiles. The  
reasoning for that is simple if you consider putting "features" in that  
not yet stabilized (in other words, the JEPs aren't done yet), you'll  
never (well not quickly anyway) agree on what features to put in it. If  
you stick to stable features, it will be relativly easy to reach agreement  
amongst the people for who this certification is most important -and who  
the whole idea of "certification" depends on for becoming a succes- the  
authors of the various clients. Ofcourse you can still have 1 person to  
oversee all this.

Just to be sure, I think these arguments are valid for both "recommended"  
and "required" features. If you intend to give the implementations of  
"recommended" features so little importance it does not matter at all for  
certification, you shouldn't put it in the certification then. Cause all  
you'd be doing then is duplicating the JEP process.

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. 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)

It could all start rather more humble though.. for example, what about  
submitting some Jabber client profiles in the form of an informational JEP?