Dave Cridland wrote: >> No, that's quite valid restriction. Client MAY cache some roster pushes >> to resume operation from the middle of "transaction" in case of broken >> connection, but it MUST NOT bump it's internal roster version until it >> gets the full "transaction" of pushes. > > We decided that each roster push was in and of itself atomic, so the > "transaction" you're referring to doesn't exist - each roster push can > be effectively treated as an atomic commit point in and of itself.
I still think it exists, let me explain my point of view more precisely.
Here is set of versions:
<query xmlns='jabber:iq:roster' ver='305'>
<item jid='b...@shakespeare.lit' subscription='none'/>
</query>
<query xmlns='jabber:iq:roster' ver='306'>
<item jid='b...@shakespeare.lit' subscription='to'/>
</query>
<query xmlns='jabber:iq:roster' ver='307'>
<item jid='shyl...@shakespeare.lit' subscription='remove'/>
</query>
<query xmlns='jabber:iq:roster' ver='308'>
<item jid='b...@shakespeare.lit' subscription='both'/>
</query>
Client knowns 305, current version is 308. The server will send 307, 308
and the notification that the latest version is 308.
Let's assume that connection was broken and client got 307 but not 308,
client does not know version 307 at the moment, as it *does* *not* know
that bill@ has subscription="to". That's why I name the set of stanzas a
"transaction" and that's why I'm against of processing interim roster
pushes until client has received all pushes.
Let me extend the example and show how things may get wrong if client
behaves in another way.
While client was reconnecting some more roster version bumps occured,
let them include some "reverting" change:
<query xmlns='jabber:iq:roster' ver='309'>
<item jid='b...@shakespeare.lit' subscription='to'/>
</query>
<query xmlns='jabber:iq:roster' ver='310'>
<item jid='nu...@capulet.lit' subscription='none'/>
</query>
Now the difference between 307 and 310 includes nurse@ but does not
include b...@. So client will not know that bill@ has subscription="to"
and will continue to assume that bill@ has subscription="none" (as it
was in version 305).
XEP-0237 does not state that server should send "final state of all
touched roster items", it should send "the final result of all changes
applied" and the result may be understood as the difference.
Am I mistaken somewhere?
Moreover, after constructing this example I don't think that caching
parts of transaction is a good idea. Caching will introduce several
corner cases.
By the way, I added nurse@ to this example to avoid sending empty
difference between two different versions of the roster as XEP suggests
no way to do that. I'm not completely sure that "unchanged" reply is the
best way to handle the situation.
--
WBRBW, Leonid Evdokimov
signature.asc
Description: OpenPGP digital signature
