[jdev] Jabber Certification Program

[Michael Gale]

Hello,

	It all makes sense to me ... I think it is a great idea.

Michael


On Thu, 17 Jun 2004 20:04:27 -0400
Rachel Blackman <rcb at ceruleanstudios.com> wrote:

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


-- 
Michael Gale
Network Administrator
Utilitran Corporation