On 4/17/09 2:08 PM, Leonid Evdokimov wrote: > 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.
Right. > «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. Yes, same as it has always been (at least since I've been involved in the Jabber/XMPP community!). >> 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". Agreed. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
