[jdev] Jabber Certification Program

Rachel Blackman rcb at ceruleanstudios.com
Thu Jun 17 19:04:27 CDT 2004

>>> And Tkabber _still_ does DTCP based File Transfer instead of 
>>> Bytestreams.  Yay
>>> for standards.
>> Then Tkabber fails its compliance and certification test.  Which is 
>> fine if they don't care, but they lose the little badge and get 
>> bumped from the list of certified clients; the clients on the list 
>> implement file transfer as per spec, and thus if you download one you 
>> know it'll file transfer with any other one on the list.
>> This seems more like an argument FOR certification than against. ;)
> Because the reward Tkabber gets for being one of the first to 
> implement experimental JEPs (this is what you were aiming for right?) 
> is that it doesn't get certification?
> I don't get it :)

What good does it do them to have DTCP now?  Does a user who grabs 
tkabber care why it uses DTCP instead of bytestreams?  All they care 
about, as an end-user, is that Tkabber doesn't do file transfer with 
other modern clients.  It doesn't interact with them in the required 
featureset, it doesn't get certification.  Period.  Tkabber doesn't get 
punished for implementing an experimental JEP.  Tkabber loses 
certification because it didn't keep up-to-date with current stuff.

Assume DTCP is something /not/ on the certification list at all, and 
Tkabber chooses to implement it.  That's their choice.  Later, 
bytestreams and /si/profile/file-transfer come out, and that /does/ 
become 'recommended' under the certification.  Tkabber chooses not to 
implement the recommendation, and gets their certification that year 
anyway because it's not a requirement.  But then, the next year, file 
transfer is a requirement.  Tkabber still chooses not to implement it, 
staying with DTCP.  Now this year they don't get their certification, 
because they no longer support current features of Jabber.

I shouldn't really define certification as something you 'lose'; it'd 
be something you have to strive to /gain/ each year.  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.

I dunno, maybe I'm off on a completely wrong tangent, but it just seems 
like it doesn't /harm/ the existing clients, but gives a way to 
encourage the adoption of various JEPs through the 'recommended' role 
-- it's not a requirement, but it gets activity on them, and a 
'recommended' feature might end up being a 'required' feature the next 
year, so it'd be good to have the structure in there and be working on 

Just my $0.02 again.


More information about the JDev mailing list