On 28.07.2015 11:58, Dave Cridland wrote: > On 28 July 2015 at 10:13, Florian Schmaus <[email protected] > <mailto:[email protected]>> wrote: > On 28.07.2015 11:05, Dave Cridland wrote: > > On 28 July 2015 at 10:00, Florian Schmaus <[email protected] > <mailto:[email protected]> > > <mailto:[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]>> > > > <mailto:[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. > > ? > > > Either a XEP-0199 request or a XEP-0198 <r/> would typically flush the > queue, in as much as the server is likely to flush it anyway, in the > rare case you want to have up-to-date presence information immediately > after switching to <active/>. Is this really every time, in every case?
The problem is not flushing the the queue, but knowing when the last flushed stanza was received, i.e. when the stream has returned to 'active'. > But your PR doesn't actually compel the server to flush presence state > and have this extra non-stanza stanza act as a sentinel indicating the > other stanzas which are not sentinels have all been sent. Not sure what you are trying to say here. Nothing in CSI even compels the server to queue presence for inactive clients. But it's obvious that if a server does so, and a client switches to 'active', then the server needs to flush the stanzas. > > > 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;)," > > > What does "after stream resumption" mean? You'd need to ensure it was > sent after the replayed messages, and the client would still receive the > <inactive/> notification message stanza. So when the client receives it, > it needs to know to ignore it because this is only a replay. Correct, it needs to be after <resumed/> and all replayed stanzas have been send. Which means in the worst case, the client gets an arbitary sequence of CSI (in)active Nonzas, followed by a final CSI active Nonza that fixes the client's view on the CSI state after <resumed/>. > and > > "The CSI state MUST NOT be keept when a stream is resumed by means of > <cite>Stream Management (XEP-0198) ยง 5. Resumption</cite>;." > > > So in order to remove a special case you're adding more special cases. Which special case do I remove? This merely tries to solve an issue with CSI in it's current state: Either we say that CSI state is kept after SM resumption, but then you run into the issue that you will end up in an inconsistent way, because CSI uses Nonzas. Which means if we want to keep the CSI state after <resumed/>, CSI needs to use Stanzas. Or we say that the CSI state is not kept across resumption, but then we need to specify the CSI state after resumption. Which is what I do here. > You're also changing a Draft spec by the back door, which doesn't appeal > to me. Which draft XEP? xep198? Where do I change it in which way? - Florian
signature.asc
Description: OpenPGP digital signature
