Dave Cridland wrote: > On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote: >> >> But that's neither here nor there. The question is whether: >> >> (1) acking an occasional roster push from the server to the client >> (where BTW the server *does* know your full JID) is a serious problem >> that we need to solve because it wastes large amounts of bandwidth >> >> > It's not the bandwidth, it's the additional transmission I'm more > concerned with. For every <iq/> stanza, there's an addition TCP data > packet, and therefore there'll be a further ACK - both of which will > cost power. > > The alternative is that we quietly explain to people that they needn't > bother replying to the <iq/> push, which I really don't like. I'm pretty > sure that the mobile developers won't want to reply to every roster > push, anyway.
You make a point. >> or >> >> (2) sending roster pushes via <message/> is a pretty optimization that >> is more elegant than what we developed in 1999, but it fundamentally >> unnecessary >> >> I think (2) obtains. Therefore I think it's just fine to keep IQs for >> roster pushes. If it ain't broke, don't fix it. > > Nothing here is necessary; the question is whether we can, and should, > do it. > > Remember, rosters are not broken right now - they work just fine. So, if > we're going to change things, we may as well consider how much we can > change things, rather than how little. I got my start in the Jabber community as the documentation guy. As a result, I've always seen it as my job to document the protocols as they are used in the community. In that sense I am a conservative, so I don't immediately think "gosh how much can we change things?" but "how little can we change to get our desired functionality?" In my opinion that's one reason our community has stuck together rather than pulled apart (with different projects and companies defining their own extensions). Changing core functionality in a significant way scares me because the feedback I typically receive is that it scares our developer community. Maybe I'm being unduly conservative here, but it seems to me that we legitimately might want to have roster sequencing without changing the core behavior of roster pushes. To summarize the discussion so far, roster sequencing enables the client to know if the roster has not changed (and this is what saves us the greatest amount of bandwidth). Beyond that I see several possible bundles, from smallest change from current behavior to greatest change from current behavior... 1. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives one old-fashioned roster push (IQ-set) for each item that has been added, modified, or removed. Subsequent roster changes are sent via old-fashioned roster pushes (IQ-set). 2. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives a "diff" -- that is, a full set of the items that have been added, modified, or removed -- in one IQ set from the server to the client (and this diff may include multiple items). Subsequent roster changes are sent via old-fashioned roster pushes (IQ-set), with one item per push. 3. If the client provides a sequence number on login and the roster has changed since that sequence number, the client receives a "diff" -- that is, a full set of the items that have been added, modified, or removed -- in one <message/> from the server to the client (and this diff may include multiple items). Subsequent roster changes are sent via <message/> stanzas, which may include multiple items. Is that an accurate summary? Are there other options on the table? Let's get clear on the options so that we can figure out which one is the best way forward. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
