Dave Cridland wrote: > On Tue Feb 19 15:00:36 2008, Joe Hildebrand wrote: >> Could this be added to XEP-198? Basically a pause command that would >> cause stuff to get buffered on the server. There would need to be an >> ack that comes back to avoid races. Additionally, I could imagine >> the thing doing the buffering could toss old stale presence stanzas >> when new ones are received from the same full jid. >> >> > You probably don't want to do it with XEP-0198, since that's fairly > low-level, and you don't want to be holding everything, just presence. A > cunning server might intercept some iq stanzas and answer them for you, > too. (If you did want to hold everything, then XEP-0198 probably is the > answer). > > Messages - as in actual IMs - you probably want to push through to the > handset if at all possible. And when you do that, it'd be sensible to > push through everything else you're holding, in one, big, neatly > compressible, blob. > > In principle, this should save a significant amount of bandwidth, thanks > to the compression effects.
The first question is: what kind of pause functionality do people want? Do we want to hold only presence, hold everything, hold everything but IMs and session-start requests (Jingle, etc.), or what? >> Combined with XEP-198 quick-reconnects (or BOSH) with long >> server-side timeouts, and it seems pretty efficient for this use >> case, at the expense of some DEFLATE performance. >> >> > Reconnections have a certain degree of impact on DEFLATE, EXI, etc, > because you'd lose state. But I'm not sure how significant that would be > - I'd personally not want to say it'll be critical without actually > testing it. > > The bulk of the data being affected by a compression codec restart is > likely to be the reconnection itself, which hopefully doesn't happen > often enough to get good compression anyway, and the post-reconnect > splurge. A clever server might rearrange that splurge to gain most from > a compression algorithm (you'd need to arrange it such that similar > stanzas were sequential), but even without that, it's one big fat > buffer, which ought to compress okay. > > Some measurements are needed here, and that's not tremendously easy > without a full XEP-0198 implementation to test against. Yeah, and XEP-0198 still needs to be cleaned up in accordance with our discussions at DevCon 3 in Portland. Unfortunately I was taking notes on the previous session at the time so I've never had a clear handle on what Justin Karneges, Joe Hildebrand, et al. had consensus about. I'll ping Justin and Joe about that soon. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
