I hope this clarifies my previous post a bit (see near bottom of email), - Dave
Matthias Wimmer wrote: > Dave wrote: > >The data loss problem, IMHO, should be solved seperately, since it's a > >general problem of delivery confirmation over an unreliable transport > >(TCP, in this case). If Jabber entities simply keep packets in their > >queues until their delivery is confirmed by the next hop, data loss will > >no longer occur. (Obviously, it'd be wise to use the TCP technique > >of piggybacking confirmations on other packets and on each other, to > >avoid crowding the network with "<message id="243" type="delivered"/>" > >responses to messages.) > > > > > What do you mean with the TCP technique? Why not confirming it with XML? > I think it's one of our strengths that we have a very simple protocol. > We just have a TCP connection and we're just sending XML over it. Sure > ... XML data is big and redundand, but that's good. If you have a bug in > and XML document you can easily fix it (even by hand) ... you can't do > this with binary data. Also it's very easy to debug, therefore you have > less bugs in your products. If you are concerned about the amount of > traffic you generate (e.g. because you connect by a mobile device and > traffic is expensive), then compress it. > Using OOB is exactly what we don't need: It would make the protocol much > harder to be implemented. There aren't many programmers that want to > deal with low level networking stuff. Also adding new XML vocabulary to > confirm delivery will be much easier to implement in existing clients > then to add OOB handling to them. Nope, I didn't mean to use binary responses. I meant to use the TCP technique of piggybacking ACKs on other types of packets (e.g., messages) to save packets. For instance, rather than sending an immediate response of "<message id="243" type="delivered"/>" after receiving "<message to='somebody@somewhere' id='243'><body>Hi</body></message>," the server would send "<message from='somebody@somewhere' id='244'><body>What's up?</body></message><message id='243' type='delivered'/>" all at once when the next message came, rather than sending the ACK immediately. I don't think we should use binary in an XML transport layer, and I don't think that's about to change. (As I've indicated in the past, I believe very strongly that Jabber should support other transport layers, but the last time I said anything about that, I got flamed to death, so pretend I didn't just say that ... hehe. . .) _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
