On 4/14/09 12:44 PM, Jiří Zárevúcký wrote: >> You are raising the scenario of the stream dying right after the server >> sends 303. I'm saying that client 1 MUST NOT consider itself to be up to >> date when it receives 303, because the server has already told it that >> the latest version is 305. Therefore, when the client reconnects it MUST >> behave as if it never received the roster push for version 303 and >> instead send the exact same roster get it sent when it came back online >> (i.e., 299). >> > > Client does not consider itself up-to-date but it would retrieve a > complete state if it starts retrieving again from that particular > point. So it could save the interim pushes as they arrive (if we > disregard the last change to the spec, which was based on wrong > assumptions).
You mean this? "The client MUST NOT process any of the interim roster pushes until it has processed all of them (this helps to prevent partial processing if the client loses its connection to the server before it has received all of the interim roster pushes)." > That could make a huge difference if the client is on very low > bandwidth, or expensive connection based on transfered data (which for > example GPRS on mobile phones). I'm not convinced of this. How often do people have a lot of new contacts in their roster? I have 2200 contacts, but even I don't always have a roster change waiting for me when I log in. Usually I have one or two subscription requests to process, but not a roster push. What is the likelihood that I will lose connectivity after the first roster push? And can't I just request the the same state I started with? I think you're making it too complicated for the typical usage. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
