On Tue, Jul 28, 2015 at 4:00 AM, Florian Schmaus <[email protected]> wrote: > 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.
Using CSI like this is an abuse of the spec, in my opinion. It was not designed as a locking / synchronization mechanism, and a new XEP should be written for this if it's something you need (actually, I have an XEP that does effectively just this that I've got a green light on and am ready to submit as soon as I hear back from the lawyers at work; will advise). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
