[jdev] Roster caching

[Dave Cridland]

On Thu May  4 23:06:39 2006, Norman Rasmussen wrote:
> Rosterx can be used to support incremental /local/ roster updates 
> too!
> 
> You still need the magic opaque integer (dns does this to remember)
> but the list of changes could be sent in rosterx format. (provides
> add,remove,update - remove the from address, and it defaults to the
> server, brilliant)

I think that's higher complexity. You're attaching a single magic 
number to the whole roster, and expecting the server to know what 
needs adding, changing and removing to get to the current version 
from an arbitrary point in the past.

In effect, the server has to perform the same operations as in my 
solution, but in my solution, the fallback case when the server has 
forgotten what got deleted is slightly neater, in principle. (There's 
an additional optimization that can cause the deletion detection 
phase to be elided, actually, anyway, by emmitting a current count of 
items in the roster, but that's almost besides the point.)

I think you score for reuse of existing Jabber stuff, whereas I score 
for reuse of other protocol's design. (To be fair, I also score for 
the little optimization I mentioned above, which genuinely is mine. 
The rest isn't.)

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