Peter Saint-Andre wrote:
> "The client can determine when the interim roster pushes have ended by
> comparing the version number it received on the empty <query/> element
> against the version number it receives in roster pushes. The client MUST
> process the interim roster pushes as it would process any normal roster
> push and MAY cache those items in case it loses its connection to the
> server during the update process, but MUST NOT increment its internal
> roster version until it receives the full set of pushes."

As far as I see, caching may be easily done only in case when "the
result" is not "the difference between two states", but "final state of
all roster items touched between two states". Otherwise caching of the
items is quite useless as the client would have to rerequest same items
on reconnection to avoid the corner-case presented above.

Please, clarify "the final result" in the phrase "The interim roster
pushes would not include all of the intermediate steps, only the final
result of all changes applied while the client was in fact offline".

If the result if the difference:
* client must not cache items (it's useless)
* server may have to store all roster versions to produce proper diffs
(at least I see no other way right now, maybe I'm wrong)

If the result if set of touched roster items:
* client MAY increment his roster version counter while processing
items. Yes, client will not know if his counter reflects "real" roster
version, but client will know that (a) he is/isn't up to date (b) roster
item [email protected] was/wasn't modified since version 42 and that's
enough for continuing incremental update in case of broken connection.
* server has to store only "mtime" of every roster item (including deleted?)

So the first method works like trivial VCS and the second one works like
rsync or incremental tar. What method is actually described in the XEP ?
Seems, that will also answer Jiří's question about `treat as normal`
statement.

-- 
WBRBW, Leonid Evdokimov

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to