[Standards] Simple Jingle example(s) and spec(s) wanted
rcb at ceruleanstudios.com
Tue Feb 6 02:04:31 UTC 2007
> 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
> 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
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.
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/
More information about the Standards