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

[Peter Saint-Andre]

Remko Tronçon wrote:
>> People who implemented XEP-0117 and did the old file transfer... if
>> there's a new one, are they still 'Intermediate IM Client'

There's a question whether XEP-0117 should include file transfer at all, 
perhaps it needs to be limited to IM and presence only, then we define a 
"media-friendly IM" protocol suite that includes file transfer, audio 
chat, etc.

> Regardless of whether or not the combination of Jingle-FT and S5B is a
> good idea, the fact still remains that the only protocol to implement
> voice in XMPP is Jingle. I have been wanting to implement the Jingle
> signaling code for a long time, but i can't even get that far because
> there is way too much to do in a first step: hardware interaction,
> voice streaming implementation, implementation of complex protocols to
> transport the streams, and *then* the signaling code . I'm pretty sure
> other people feel the same way as well. This is why I want a file
> transfer profile of Jingle: so that I can completely focus on the
> signaling code without worrying about anything else (which is already
> a complex state protocol in itself), and have that tested in a first
> step. Then we can start focus on all the dirty stuff like transports
> and media hardware interaction.

That makes sense to me as a bootstrapping approach.

> Personally, I think the current spec is nice, works from time to time
> and from implementation to implementation, but then again, i'm overall
> disappointed in its performance.  

Others are too. I know I am. Is NAT/firewall traversal the fundamental 
problem, is the lack of reliable proxies, or what?

> All I want is something that works,
> and let's face it, the only guys that came up with that so far are
> Google. 

I don't know how their HTTP over TCP over Jingle stuff works but it's 
always sounded scary to me...

> Since they are definitely interested in interoperability with
> other clients (libjingle), I'm pretty sure they seriously considered
> using the current spec, but found it inadequate. What's even better,
> besides going through the effort of creating a library on the side to
> help interoperate with their protocol, they are willing to put effort
> in cooperating to make an improved standard which, although similar to
> what they have right now, still requires an additional effort from
> their side to implement and comply to as well.
> 
> Personally, I don't mind implementing both specs in a client. If the
> step from a protocol for voice (which we need as well) to a protocol
> for file transfer is minimal, and if the file transfer protocol makes
> it easier to implement the voice signaling and firewall traversal (and
> even voice) step-wise, then why not use it? A client just starting up
> would only have to implement one protocol, and have it extended to
> have capabilities like voice, video, ... It would already clean up a
> few XEPs from the 'long' XEP list.

That's the dream, anyway. :-)

Look, I'm not happy about the plethora of extensions, either. I don't 
want three ways to do avatars, three ways to do file transfer, three 
ways to do end-to-end encryption, etc. In part, we have multiple ways to 
do certain things because we didn't know what we were doing in 1999 or 
2000 and came up with approaches that didn't really solve the problem 
(file transfer via jabber:iq:oob?). The audience for our protocols has 
changed (in 1999 it was just fine to do e2e via PGP because, well, don't 
all our developer friends have PGP keys? but that doesn't work for Aunt 
Tillie), the technology landscape has changed somewhat (ubiquitous NATs 
and firewalls), etc. Yes we could see those "reasons" as just excuses 
and maybe they are. But we're trying to do the best we can and fix the 
some parts of the car as we're hurtling down the highway at 65 miles an 
hour. The process is not always pretty or pleasant. I wish it were, but 
it isn't. Maybe we need to do a better job of showing developers what 
the migration paths are. Maybe we need to do a better job of incenting 
developers through code bounties (the XSF has the money, let's use it 
for good). I'm open to any and all suggestions. But let's not stick with 
broken extensions that don't really solve the problem at hand, just 
because the extension is already defined. I don't want to throw things 
out if they work just fine. But I also want to make sure that we have 
working protocols, instead of half-working extensions that lead to a 
poor user experience (as I think we have right now with file transfer).

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070206/8299ad7b/smime.bin