[jdev] Re: Roster caching

[Dave Cridland]

On Fri May  5 07:38:36 2006, Remko Troncon wrote:
> On Thu, May 04, 2006 at 03:33:03PM -0600, Peter Saint-Andre wrote:
> > objections to it. I'm not sure how much demand there really is 
> for this
> > feature, but server and client developers could experiment and 
> see if it
> > makes life much better for all concerned. :-)
> 
> Well, i must confess that each time i log in with my 'main' jabber
> account and MSN account with XML logging on, i always shiver about
> the size of my contactlist(s) being sent. When logging in over a
> cell phone connection, i lose a lot of initial traffic (11k 
> uncompressed)
> just retrieving my roster. This is why i created a special account 
> with
> my most important contact, to use in bandwidth-challenged 
> situations.
> I realize stream compression would help me a lot, but such an 
> optimization
> sounds like a good way to avoid traffic altogether.
> 
> 
Well, I'm the the happy position of having stream compression on my 
email, and I can tell you for certain that the protocol optimizations 
there help considerably more than the compression - although 
generally, for email usage, I'm seeing 60%-80% reduction in data 
transfer even after those protocol optimizations.


> I like the direction of Dave's proposal. However, at first i read 
> it as 'keeping one number for the total roster', kind of like how 
> subversion manages
> repositories. This makes adding, deleting, ... and such easy, and 
> doesn't
> require the other operations (like obtaining a list of deletions,
> obtaining a list of entries). However, this requires more (smart) 
> storage i guess. The one number per entry works, but it makes 
> deletions pretty tricky to implement and track, both server and 
> client side, and sounds like you can get into a mess pretty fast.
> 
> 
If it helps, I've implemented both side (client and server) of that 
mechanism for ACAP. ACAP has per entry ACLs, so it's significantly 
more complex to implement the deletion tracking, hence for any ACL 
change, I throw the deletion tracking data (tuples of modtime and 
entry name) away entirely, and force the client into using the 
fallback. This is cheating, but it's a fairly rare case in practise 
anyway. I also don't persist the data, so if the ACAP server crashes 
it's lost.

The deletion tracking isn't that hard (hardest thing to remember is 
to scan the deletion tracking list when you create an entry, to 
ensure you're not going to report it as both changed and deleted). 
Nor is the modtime stuff (as it's called in ACAP - moseq is from 
IMAP, and is in reality somewhat more complex), that's a pretty 
trivial job, in fact.

On the client side, dealing efficiently with the deletions is hard, 
but if you want, you can use simpler fallbacks than I do, like, if 
the deletion tracking fails, you just refresh the entire roster. I'm 
just a little obsessive about saving octets on the wire. Note that 
it's easier if you're dealing with data that has update notifications 
anyway, since you wire the deletion tracking (and the modified-since 
search results) into the update handling.

So basically, the upshot is that I'd dispute that implementation of 
this is particularly difficult - I'd stop short of trivial, at least 
for clients, but when you start being clever about bandwidth, your 
client does have to be a little smarter to take full advantage.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw