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

[Rachel Blackman]

> 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:

Okay, lemme address these points first. :)

>
>  * 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.

Trillian 3.1 supported fallback to S5B proxy servers, albeit not  
IBB.  I know I'm far from the only one that supported S5B proxies.  I  
do agree that the S5B proxy adoption has not been sufficiently  
widespread to make it a completely workable option, however.

(Astra, being a complete rewrite and in alpha, is at a point where  
I'm now examining my file-transfer options.  Hence why this issue  
actually has some relevance to me; should I just do the new Google  
method, or should I implement the old one, etc.)

>  * Google Talk doesn't support existing file transfer XEPs (unless we
> can get them to implement them).

I'm not certain I agree that 'because someone else doesn't use the  
existing accepted (DRAFT) method, and wants to develop their own' is  
sufficient reason for this.  I agree that creating client-specific  
features in a client-specific namespace as an experiment is a viable  
method; I'm just not certain that creating client-specific  
alternatives to /the accepted, existing XEPs/ is a good road to  
follow.  At the very least, I'd argue it's behavior that shouldn't be  
encouraged!

We already have enough problems with this.  And if we have a second  
file-transfer method... let's say that Psi uses stream-profile, and  
Google Talk uses Jingle-FT, and maybe Apple comes up with their own  
specialized iChat-FT (on the grounds that they, too, have a method  
for establishing client-to-client streams).  Now if I want to send  
and receive files with all of my contacts, I have to implement /three  
different/ file transfer specifications.  And not just file transfer  
specifications, but /entire stream negotiation methods/.

(It is at this point that most client authors go sit in a corner and  
start to sob uncontrollably.  Or throw in the towel and use AIM.   
Just sayin'.)

I'm not saying that Jingle-FT isn't the right solution, or that  
deprecating stream-profile might not be in our best interests.  If we  
all agreed on a single stream-negotiation method for all different  
forms of media (including audio and video... Google, Apple, I'm  
looking at you guys here!), that would be great.  I'm just saying  
that this is not something we should necessarily just sort of nod and  
go 'okay, yeah, we'll do that' without looking at the consequences!

I personally believe that clients /should/ have a recommended set of  
features they need to implement, and this set of recommendations  
should shed outdated protocol (and take in new, updated protocol) as  
time goes on.  In such a situation, Jingle could replace the existing  
stream profile/S5B/IBB XEPs, and the various transport XEPs that use  
stream profile could be updated to use Jingle.  Tada!

However, I am not certain I feel like tilting at that particular  
windmill again; Julian Missig and I tried that back in June 2004, and  
were shouted down by a number of folks. ;)

We suggested coming up with a certification program for clients, with  
yearly requirements and testing to maintain certification (and  
certified clients would get onto the old jabber.org client list), and  
we were met with a lot of unhappiness about how certification would  
become political, or it would 'damage' clients to lose certification  
if they didn't update.  (The example, ironically enough, was that it  
was unfair to require clients to update from DTCP to steam-profile/ 
S5B file transfer...)  Similarly, a certification for servers  
would've been able to push S5B proxies by making it a requirement of,  
say, the 2005 or 2006 server certification set.

It was a rather unpopular idea, so we dropped it.  But I admit I just  
sort of feel like we're right back at the same place as we were two- 
and-change years ago...

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/