2009/4/14 Dave Cridland <d...@cridland.net>: > > I shouldn't reply to these things so late at night. >
I shouldn't write them so late at night in the first place... :) > > I'm not sure they replace, as such - collapse might be a better word. > > Changing both subscription state, and, later, changing name, results in a > single roster push containing both changes. However, changing name twice > will effectively replace. > You can't do that. See: <query ver="300"> <item jid="cont...@example.org" subscription="none" /> </query> <query ver="301"> <item jid="cont...@example.org" subscription="none" name="Contact" /> </query> <query ver="302"> <item jid="cont...@example.org" subscription="to" /> </query> Now there is no name, as the last push erased it. If I'm mistaken in this and one of the attributes can be left out to signify "don't change it", it has to be made explicit in the spec anyway, as normally leaving out name means "remove". ----------------------- But I realized there is a rare scenario where it could really cause problem. <query ver="300"> <item jid="b...@example.org" subscription="none" /> </query> <query ver="301"> <item jid="al...@example.org" subscription="none" /> </query> <query ver="302"> <item jid="b...@example.org" name="Bob" subscription="none" /> </query> <query ver="303"> <item jid="al...@example.org" subscription="to" /> </query> <query ver="304"> <item jid="b...@example.org" name="Bob" subscription="from" /> </query> <query ver="305"> <item jid="b...@example.org" name="Bob" subscription="none" /> </query> Client knows 300. The roster would send 303 first, and 305 second. If connection failed after sending 303, client would next request 303+, but never received 302 in the first place. Now (only) in case the server checks the last state client should know, it will find out it doesn't need to send the push since there is the same state as in 302. Client wouldn't receive bob's name until next change. That is easily fixed by disallowing servers such checks.
