Hi,
On Feb 27, 2008, at 9:19 PM, Alexander Gnauck wrote:
Fabio Forno wrote:
I like this one, since it always has a backup when no sinchronization
is needed. Moreover the server can store only a window of changes,
and
send the whole roster if the last known by the client is too old
+1, I don't think we want to keep all roster revisions from the
beginning. If servers will give us such a option this is great, but
I don't think it should be required.
For "normal" usage about 100 revisions should be fine.
well, in practical terms, if we store a generation_id on each roster
entry, that gets updated for each entry modification, and assuming a
SQL-style roster store, keeping changes "forever" costs you the size
of the generation_id field per entry, and you can just add a WHERE
generation_id > SENT_BY_CLIENT to the usual SQL.
So I would vote for a generation/version-style solution.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
