Hey all, I 100% agree that a certification process would help drive adoption of JEP's. The long JEP list is simply way too daunting for new client authors at the moment, and knowing which JEP's are "blessed" by the community would help those authors greatly, and would encourage them to do the extra work of supporting more than basic XMPP.
I think a big part of this debate has boiled down to semantics. It's pretty easy to agree that it would be useful for client authors to know which experimental JEP's will likely soon be required for certification (after those JEP's are no longer experimental). What to actually label those JEP's is another question. They could be "recommended", or "upcoming", or some other label -- basically it should just tell people that they should start working on supporting a set of experimental JEP's so that: 1) They can be ready for when they are required during ceritification. 2) They can provide practical feedback on the JEP and help move it from experimental to certified. The label debate shouldn't distract from the larger issue, though, which is that it would be great to have a certification process in place. Regards, Matt > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rachel Blackman > Sent: Friday, June 18, 2004 10:33 AM > To: Jabber software development list > Subject: Re: [jdev] Jabber Certification Program > > >> 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. > > I think I phrased this badly, so I'll try again in a moment > to summarize my intent in this proposal. However, I would > submit that you are getting rather sidetracked by making this > a debate over motives rather than benefits or drawbacks to > this; regardless of /my/ intent in putting this proposal out > there, surely you have your own opinions on what benefits or > drawbacks this proposal has? That was in large part what I > was interested in hearing from others. ;) > > Okay. Trying to summarize my intent again. > > Right now, there are lots of features out there. To use > XHTML as an example (or file transfer in the older days), > because of the fact there is an attitude (rightly or wrongly) > that implementation of experimental JEPs should be > discouraged, sometimes we see custom extensions to clients as > interim solutions. (Witness various client-specific mutant > HTML-marked-up message implementations.) > > A certification program would: > > 1) Encourage standardization and interoperability, as > anything 'certified' would be pretty much guaranteed to > interoperate probably with the other certifications. > > 2) Indicate (through 'recommended' features in each year's > certification definition) features which are not yet required > for certification but which will likely be required in the > following year. > (Including experimental JEPs.) > > 3) 1 and 2 together; instead of spending effort making an > 'interim solution' specific to your client while there is no > clear non-experimental solution, all the client authors > striving for certification and interested in a feature would > thus have an incentive to concentrate their efforts on making > a standard. The JEP process is supposed to be driven not > only by the Council but by the community, and this would > drive community action. Let's say someone wants a webcam > solution in their client, but the only webcam JEP is > Experimental and unfinished, not in a state where it can yet > be implemented; if that webcam JEP is on the 'recommend' list > for certification, then instead of going 'well, that JEP will > not be Draft for a long time so I will just make my own > client-specific solution for now,' the developer has an > incentive to really push the JEP process forward, flesh out > the JEP and so on. Someone wanting certification is not > required to implement the webcam JEP or participate in moving > it forward, but might want to watch it if it is a potential > for, say, the next year's 'Jabber Media Client' certification > or whatever. > > (This is not to say I think webcams will ever be a > requirement on any certification, but I needed an example to > pull from thin air.) > > > 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!). > > To uses your example, let's say that the old avatar > specification was 'certified' one year, and then it's found > to be bad, and it's replaced. > Now you put the new avatar specification into the > certification; those who want to keep their 'certified' > status implement this. Those who do not implement it do not > get certification again. > > I would say the problem is twofold. > > First, there is not a direct incentive to work on pushing JEPs forward > -- implementing them, experimenting, finding their flaws and > strengths and thus revising them so they mature -- and in > fact (as has been seen in this thread), there are developers > who actively /discourage/ people from implementing > Experimental status JEPs, meaning they sit and languish. > > Secondly, there is no direct incentive to update to more > current JEPs (save for interoperability) when ones go away. > With existing clients doing the old-style deferred avatar > method, I will bet you that many will not consider it a > priority to move to the newer avatar specification when it > gets finished, which does hinder the adoption of newer > protocol extensions. In fact, this state of affairs > encourages adoption of OLDER methods; if a new client author > comes in, and wants to do avatars, and finds only one other > client does the new pubsub method but five or six use the old > method, I suspect the author in question is going to > implement the old method as well. > > > 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. > > Hence why you need the Certification Board to manage this, > hence the original proposal. And yes, it isn't that it could > be "called" > certification, that /is/ what was intended as certification. ;) > > > 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) > > Interoperability testing and standardized featuresets is a > lot of the motive behind this, but my experience with other > projects in the past is that something like a 'Certified' > badge (and some kind of benefit to go with it) would drive > the standardization and interoperability better than just > saying 'hey, let's make it all work together.' You catch > more flies with honey than debate, or something like that, to > mangle a metaphor. > > --Rachel > > _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
