On 3 June 2015 at 00:48, John Williams (johnwi3) <[email protected]> wrote:
> Thanks for the clarification. > Hum,.. not sure how useful this is, since a lot of stanzas are of little > long term interest (eg: chatstates), but as you describe it seems pretty > harmless. > > So as things stand, if a TCP virtual circuit is lost (due to, for example, wandering out of signal), then the choices are: a) Drop the session (the only option without XEP-0198). b) Keep the session live (with XEP-0198). If a server keeps the session live, it's got to keep the state (things like current presence broadcast, directed presence, and so on). In addition, other users will see the session as live, and while PSA might help indicate this by annotating the presence, it's still a bit weird. Fine for handover periods, but not so good across a half-hour underground train journey. It's worse if the client never resumes, of course. So servers in effect have to timeout such zombie sessions, and it needs to happen within a few minutes before the UX issues pile up. Whether a session is dropped immediately or later, a server can essentially redeliver the outstanding stanzas; risking duplication. On the other hand, when the session is dropped, stanzas that are "in flight" from the client are lost. Many of these may well be unimportant in a non-resumption case, but it's useful for a client to know if that message saying "I'm just jumping on the train, be there in 30" actually got as far as the server. What this minor addition does is allow the server to tell a client, "That message got through, but I don't have the rest of your session state - you'll have to start a new one". In principle it could also figure out which of the pending offline messages the client already has and discard them, too. The cost for this is storing one server-chosen string, plus one or two integers - that volume of data can be persisted fairly cheaply, and possibly even offline. Think of it as a failure with benefits. Dave.
