On Sun, 2010-01-24 at 20:53 -0700, Peter Saint-Andre wrote: > On 1/24/10 7:12 AM, Ralph Meijer wrote: > > On Fri, 2010-01-22 at 21:15 -0700, Peter Saint-Andre wrote: > >> A number of XEPs are due to be deferred in the next 4-5 weeks. Here is > >> my take... > >> > >> [..] > >> > >> 4. XEP-0247: Jingle XML Streams > >> http://xmpp.org/extensions/xep-0247.html > >> > >> IMHO we don't need this one any longer, so it can lapse without issue. > > > > Just last week I suggested Dan Brickley to look into this XEP, because > > it enables low-latency peer-to-peer XMPP traffic without requiring > > Zeroconf support. > > > > While I very much admire Zeroconf and the Serverless Messaging > > specification (XEP-0174), using it in a heterogeneous environment can be > > a challenge. Support for mDNS and DNS-SD are often part of the OS, and > > have different APIs on every platform. For example, Linux-based systems > > have Avahi. > > Right. But what's the problem? The fact that you can't write once, run > anywhere (different APIs)? Or the fact that some platforms don't have > support for mDNS and DNS-SD?
Both, actually. > > Also, if you already have a path between entities through the regular > > XMPP network, it makes perfect sense to use Jingle to establish a direct > > XML Stream in the face of low-latency requirements. Dan's example would > > be a media center remote control. > > Direct over what transport? TCP? I suppose that might work on a LAN or > home area network (HAN) or even a neighborhood area network (NAN), which > is the use case that Dan cares about. Hmm, Dan/LAN/HAN/NAN? ;-) :-) Yes, I believe LAN is the objective here (sitting with your mobile phone in front of your media center). That said, end-point discovery might still be a challenge. Definitive matching of end-points both in and out of bound still needs to happen. Trial and error with several candidates, like in similar audio/video streaming scenarios, is a possibility. Some combination of Zeroconf and Jingle could probably help as well. > > I'm not particularly convinced about the usefulness of the required > > implementation of IBB in XEP-0247, though. If you already have a > > serverful path, but cannot establish a peer-to-peer stream, you can just > > do the exchanges through regular XMPP, without envelopes. > > I think the reasoning was that we have IBB and anything else you design > will look an awful lot like IBB, so why not re-use that? Well, for both in-band and out-of-band structured XML exchange, in this particular scenario, you could use the exact same stanzas, complete with addressing. The only difference being the route. For in-band, your stanzas go through some servers, for out-of-band over the specially established peer-to-peer XML Stream. It seems pretty useless to encode a stanza in base64 and wrap it in an envelope with the same addressing. Unlike streaming binary, the fallback can simply be the regular XMPP network. Anyway, the raison-d'être of this specification might be thin. Low latency is the foremost advantage I can think of. Lack of platform support, or ease of implementation in them, is probably not a very good reason for new protocol. Serverless Messaging would then be the solution, albeit without an obvious way to match entities, so far. ralphm
