[jdev] Jabber Certification Program

[Matthew A. Miller]

Ms. Blackman is not advocating certification for its own sake.  The 
piece that I think was left unsaid was that there's all these cool specs 
for features, and users have a real desire to have those features, yet 
client haven't implemented them.

As a case in point, I refer to a fairly-recent thread in this very list 
on a "deficiency of the protocol"[1] for file transer.  The findings: 
not every client tested implemented file transfer according to spec. 
Yet the file transfer specs have been available for nearly a year.

How could certification help?  If we had certification, it would be a 
certainty that a list of certified clients would be available.  A user 
could obtain the list of clients "certified for file transfer", and know 
that their chances of success are vastly greater than if they just 
started downloading clients.


-  LW

[1] http://www.jabber.org/pipermail/jdev/2004-June/018627.html

Tijl Houtbeckers wrote:
> 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?
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev