[jdev] XMPP Summit
dmeyer at tzi.de
Wed Dec 10 13:52:25 CST 2008
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-
>> 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
>> some ideas. Maybe we can discuss it, too.
> Streaming audio/video where you can seek? :)
> 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 , why not XMPPFS?
Life's unfair - but root password helps!
More information about the JDev