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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
