Please implement XEP-198 (stream control)

[bugs.bitlbee.org@…]

Currently, if there's a network hiccough (or a mobile client gets a new IP address), Jabber messages get lost between server and client, despite the TCP transport. XEP-198 fixes this, but it needs support from servers and clients.

Please implement XEP-198 (which should be trivial) in BitlBee!

[dx]

Wouldn't it be enough to handle errors from XEP-198 clients, as #1114 says? BitlBee is not a mobile client, network issues are supposed to be a rare thing.

(which should be trivial)

​lol

[bugs.bitlbee.org@…]

Yeah, you busted me on that trivial comment! ;)

Anyway, BitlBee is not a mobile client, but it may well run on a link with persistent network problems or IP changes.

You are right though, #1114 seems more important.

[dx]

We talked about this issue in #bitlbee a few weeks ago with the_eye (the one who submitted #1114 - adding him to CC), he made a really good series of blog posts detailing the current situation (​starts here, ​list).

The main problem with both this ticket and #1114 is that we're trying to be as stateless as possible, and XEP-0198 requires us to track the state of all messages. We sort of figured out a way to avoid having state for #1114 by giving the messages meaningful IDs, so all that's left for that ticket is, well, *cough* to actually write it. But for an actual XEP-0198 implementation there's no way we can avoid tracking everything.

But I can understand that this can be desirable, and, well, we have other 300 tickets open, so it won't hurt to leave this one around if we ever figure out something.

[wilmer]

I only gave the XEP a quick read, it looks like you need to request ACKs from the server on whether everything sent up to that point has arrived or not. So if stuff is just kept in the transmit buffer until the server has acknowledged it, that doesn't mean too much state tracking.

But I might be wrong, didn't read it all very carefully.

Still, yeah, a fair chunk of work.