[jdev] Jabber Certification Program
Matthew A. Miller
linuxwolf at outer-planes.net
Fri Jun 18 12:26:22 CDT 2004
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" 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.
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
More information about the JDev