Peter Saint-Andre wrote: > Dave Cridland wrote: >> On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote: >>> In section 2.4, would it be easier to implement in existing clients if:
<snip/> >>> - All changes would be sent to the client as roster pushes after the >>> iq/response, ordered such that the last one had the current version >>> number > > I pondered that for a while before settling on the diff. My main concern > with the roster-push-only model is that there could be an awful lot of > roster pushes, each of which (1) has TCP and IQ overhead associated with > it and (2) needs to be acked by the client per RFC 3920 (but in practice > not all clients do this). But if there would be lots of roster pushes > (where "lots" is defined by that smart server to which your dumb client > is connected) then the server could send you the complete roster, right? > >> That's quite a neat design. It eliminates the diff attribute. > > Yes, I think it would. > >>> Then, all I have to do is store my current roster, and apply diffs to >>> it in exactly one way. >>> >>> >> Yes, I like this. > > It's definitely worth pondering some more. OK, I pondered it some more. I think the roster-push-only design is superior, because clients already know how to handle roster pushes, whereas they don't know how to handle roster diffs. If we can define roster sequencing in such a way that it uses only the primitives that clients already understand (full roster and roster push), then clients will be more likely to implement roster sequencing. And that's a Good Thing. Now we just need to describe a good rule of thumb for servers to follow in deciding whether to send the full roster or a series of roster pushes. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
