[Standards] mobile optimizations

[Peter Saint-Andre]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080220/2ee5ce34/attachment.bin