Jiří Zárevúcký wrote: > Example 4. Roster result with no content > > <iq from='[email protected]' id='r1' to='[email protected]/home' > type='result' /> > > Example 5. Server sends any changes since the clients state as ordinary pushes > > <iq from='[email protected]' id='p1' to='[email protected]/home' type='set'> > <query xmlns='jabber:iq:roster' ver='313'> > <item jid='[email protected]' subscription='remove'/> > </query> > </iq> > > <iq from='[email protected]' id='p2' to='[email protected]/home' type='set'> > <query xmlns='jabber:iq:roster' ver='317'> > <item jid='[email protected]' subscription='both'/> > </query> > </iq> > > > The client can't figure out which push is the last change, but that > doesn't matter, since all pushes are atomic.
«Example 2. Roster result (unchanged)» equals «Example 4. Roster result with no content». Yes, I understand that it's ok to send same reply in both cases as it has following semantics: «roster updates (if any) will be sent as subsequent roster pushes». The client can't figure out which push is the last change, so it can't send initial presence after receiving up-to-date roster as client never knows if it is up-to-date. I don't know if that really matters, but that interferes a bit with RFC3921: | 7.3. Retrieving One's Roster on Login | | Upon connecting to the server and becoming an active resource, a | client SHOULD request the roster before sending initial presence | (however, because receiving the roster may not be desirable for all | resources, e.g., a connection with limited bandwidth, the client's | request for the roster is OPTIONAL). So client SHOULD request roster and send initial presence without waiting for the roster to came. > To rule out several possible corner cases, server MUST always send > pushes for every changed item, even if there were several changes that > in fact reverted itself. That means the server MUST NOT send a simple > difference, but instead MUST send all the items that were modified at > any point in history. Right, that's exactly what I called "rsync-way". -- WBRBW, Leonid Evdokimov
signature.asc
Description: OpenPGP digital signature
