[jdev] XMPP Summit

[Dirk Meyer]

Jonathan Schleifer wrote:
> Am 10.12.2008 um 20:11 schrieb Dirk Meyer:
>
>> Great. A question to day 2: I guess the priority will be on "XMPP as
>> Skype replacement", so RTP over Jingle, ICE-UDP and friends. But we
>> should also have a discussion about the future of Jingle for TCP-like
>> requirements like file-transfer and e2e streams (see day 3). So ICE- 
>> TCP
>> or something like this comes to my mind. I never was on an XMPP summit
>> before, but maybe split the Jingle discussion into three parts: Jingle
>> basics, UDP (VoIP), and TCP (ICE-TCP, TURN, etc).
>
> Well, actually, UDP for file transfers can be desirable if you want to
> circumvent NAT. :) So UDP can work where TCP doesn't. Of course, you
> then need integrity checks.

I know. But maybe one client is not behind a NAT. In that case we could
open a TCP connection directly. Or one client behind a NAT has UPnP IGD
or NAT-PMP support in the router. It would be a shame to go into the UDP
trouble if one of these solutions work.

>> And one note to file transfer on day 3: are there any ideas to support
>> seeking in file transfers? It would be a nice feature and I already
>> have
>> some ideas. Maybe we can discuss it, too.
>
> Streaming audio/video where you can seek? :)

Yes.

> Maybe this should be implemented in Jingle Audio/Video and not in
> Jingle File Transfers. 

I don't like RTP for my use case. Why sacrifice a packet that is too
late when you are watching a video from your home server? I don't need
the real-time from RTP in this case. I will go into details in a post on
the standards list. Give me some time to sort my memory. :)

> But OTOH, seeking in File Transfers would allow
> something like XMPPFS :).

And it shouldn't be too hard to code for Linux using Fuse. I wrote a
small Fuse filesystem once, not a big deal. It sounds like a very crazy
idea ... I like it. :) If there is djmount [1], why not XMPPFS?


Dirk


[1] http://djmount.sourceforge.net/

-- 
Life's unfair - but root password helps!