[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
it.
Just my $0.02 again.
--Rachel
More information about the JDev
mailing list