Just to back-track a bit... I agree that making non-conformant standards (like Google did) isn't the best for client support: in some cases it pushes things that are otherwise required.
Look at the X-GOOGLE-TOKEN it was a feature that wasn't covered by the standards. Even though it was unnofficial it has a very big client coverage now. Let me quote from <http://dystopics.dump.be/2006/02/04/the-mysteries-of-x-google-token-and-why-it-matters/> "Hold on, Google Talk/XMPP isn't just a SSO service, it's one that _EVERYONE_ can easily implement on their site, without the need for licensing fees and all! All your clients need is a free Gmail account." As you can see X-GOOGLE-TOKEN really does provide a lot of value to the community. The XSF doesn't always have time to handle 1 million requests for new standards. Having someone implement them before-hand really takes a bit off the XSF's table and allows them to see that the standard really would work. For example, I want to implement an entire remoting framework on XMPP (not RPC/RMI, but true remote living objects): instead of wasting the XSFs time with a plea for a standard I can implement it and proceed to demonstrate it at some point and hopefully get some feedback. This raises an interesting point. Given that the XSF doesn't always have time to document a standard, what do we do? I think the best way would be to: 1. FIRST check if any XEP supports exactly what you want. 2. Document your protocol outlining clearly the requirements. 3. Check if a combination or appropriation of any XEPs can facilitate this (my one will probably use ad-hoc commands). 4. Proceed to implement your application (which should be seen as far as possible as a prototype). 5. Approach the XSF and say, "here are my requirements, here is what I thought would be an appropriate protocol, and here is a working prototype". But that is just my opinion. I think one thing that is important is that not final product should be pushed until a go-ahead is received from the XSF (which Google did not do): as I do see it as critical in making sure that a protocol is properly defined, peer reviewed and widely accepted (as well a being unique). Any comments? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Sander Devrieze > Sent: 16 May 2008 12:50 AM > To: Jabber/XMPP software development list > Subject: Re: [jdev] Facebook XMPP > > 2008/5/16 Peter Saint-Andre <[EMAIL PROTECTED]>: > > On 05/15/2008 4:33 PM, Sander Devrieze wrote: > >> 2008/5/15 JabberForum <[EMAIL PROTECTED]>: > >>> I aggree. I don't really see a point in having an open letter. They > know > >>> of our existence, and they'll contact us soon enough. > >> > >> An open letter > > > > I don't believe in open letters. How gauche! > > > >> maybe can be useful if it is done as some kind of press > >> release. > > > > Issued by whom? The XSF issued its last press release on 2007-01-16 > and > > we (that's the royal we) decided that we would stop doing press > releases > > because they are *so* 20th-century. Now we just blog: > > > > http://blog.xmpp.org/ > > "some kind of" can be readlike that for example. > > >> First contact several potential walled garden owners and get > >> them to support the open letter by switching to XMPP. Then list them > >> in this letter or let them publish this letter or something like > that. > > > > There are much better ways to convince companies to federate. > > Maybe, but it's never wrong to look at all posibilities > > >> Overview of the battle field, > > > > Who said anything about a war? > > The "playfield" if you like that better ;-) > > -- > Mvg, Sander Devrieze.
