On 28.07.2015 11:05, Dave Cridland wrote: > > > On 28 July 2015 at 10:00, Florian Schmaus <[email protected] > <mailto:[email protected]>> wrote: > > On 28.07.2015 10:20, Dave Cridland wrote: > > > > > > On 28 July 2015 at 08:22, Florian Schmaus <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On 27.07.2015 23:29, Sam Whited wrote: > > > Hi all, > > > > > > I'd like to propose that the Council vote to move XEP-0452: Client > > > State Indication into last call (the "Proposed State"), and then > > > hopefully into draft afterwards. > > > > > > The XEP has been sitting dormant since it was last updated almost > a > > > year ago (2014-08-28). > > > > I've talked to Matt at the Summit this year about a message > notification > > send by the server to the client indicating a successful CSI state > > change. We agreed on the change and I sent a patch to Matt a while > ago. > > But the patch was not applied since then. I've created a PR now: > > https://github.com/xsf/xeps/pull/34 > > > > > > What? Why? What can a client do in response to the information? > > The client knows for example that the roster presence information is > up-to date. Basically I've an use case of a client using CSI which needs > to take a decision based on the current presence state of the roster > items. Imagine the following scenario: Client is in CSI inactive state, > an external event triggers the client so that he needs to make an > decision based on the presence state of the roster items. In order to > get the latest presence information, the client switches to CSI active > and waits for the queued presence stanzas to arrive. Without the CSI > state change message notification, the client can't decide when the last > queued presence stanza has arrived. > > And yes, I know that presence information can be always considered as > outdated. Because even if you don't use CSI, the client's view of the > presences could not reflect the state the client's roster items actually > have. > > But having such a CSI message notification is a trivial change to CSI, > and provides a huge benefit for this use case. > > > So switch mode and ping.
? > > Also, why wrap the server notification in a message, > > And not using a Nonza? Because most libraries provide a mechanism for > callbacks matching a given filter only for Stanzas. It's my impression > as as XMPP client library developer, that we don't want Nonzas to > trigger callbacks on the client side, as it would increase the > complexity of XMPP client software stacks. > > > It's very wrong. > > Consider a case where the client goes active, then switches to inactive > but loses connection and recovers via '198. The response - which is > tightly bound to the session - would indicate that the client was > inactive, but would arrive on a subsequent connection which is not inactive. That's why https://github.com/xsf/xeps/pull/34 adds "CSI enabled Servers MUST send an <active/> CSI notification after stream resumption (&xep0198;)," and "The CSI state MUST NOT be keept when a stream is resumed by means of <cite>Stream Management (XEP-0198) ยง 5. Resumption</cite>;." - Florian
signature.asc
Description: OpenPGP digital signature
