[Standards] Simple Jingle example(s) and spec(s) wanted

Matt Tucker matt at jivesoftware.com
Tue Feb 6 01:10:09 UTC 2007


Rachel, 

> If Jingle is the 'new stream transport system,' that's fine, 
> but it's starting to look dangerously like we have two 
> entirely separate methods for /negotiating raw streams 
> between clients/, and that's not even getting into the 
> various methods of stream transport that each can negotiate.  
> If stream profiles is the method for negotiating TCP streams, 
> and Jingle is the method for negotiating UDP streams, that's 
> fine too (although I'd argue that file transfer is properly a 
> TCP stream rather than a UDP one).

I think the assumption is that Jingle will become the one way to do
streams (UDP or TCP) and that the existing stream stuff and file
transfer XEP's will be deprecated. There's a couple of reasons this is
probably a good idea:

 * The existing file transfer XEP's generally break with firewalls,
unless you implement failover to other mechanisms (try p2p, then proxy,
then ibb). Only Spark does this currently as far as I know.
 * Google Talk doesn't support existing file transfer XEPs (unless we
can get them to implement them).

> Maybe I'm overreacting, but I'm already seeing a place down 
> the road where we have multiple incompatible file transfer 
> methods, and that's not going to help client 
> interoperability.

The XSF has always taken a "let the developers" decide approach, but I
agree that things are getting a bit out of hand with the number of XEP's
and the confusion they generate. A few things might help:

 * Organize the default list of XEP's around the Basic, Medium, and
Advanced profiles. That will give developers a much clearer picture of
what needs to be implemented in new clients.

I'm picturing a three column layout:

Basic   | Medium | Advanced
-------------------------
XEP-A   | XEP D  | XEP E
XEP-B   |        | XEP F
XEP-C   |

 * Move informational XEP's to a different listing by default. Actively
attempt to get support for them phased out by providing finalized
versions of standardized XEP's and and adding notes discouraging
implementations of the older XEP's. For example, there's still no good
alternative to vCard, so everyone has to use it.
 * Add back server and client feature scores to the xmpp.org website,
but modernize them. That gives client and server authors massive
motivation to bend to the will of the XSF in terms of XEP-compliance so
that they can get a top listing. For example, if I look at a XEP and can
see that a little box in the corner of it that shows that I'd earn 2
points in the feature matrix score for implementing it, that's great
motivation.

-Matt 



More information about the Standards mailing list