* Christian Schudt <[email protected]> [2015-07-28 10:22]: > I think this has already been discussed once, but wouldn't it be more > intuitive to use IQ semantics for this instead of sending a message > which confirms the (de)activation?
+1 for an IQ. Basically just what google:queue does, with a properly declared namespace and its own XEP. IMO, the discussion about a session forced to be CSI-active after resumption is only a workaround due to the fact that (in the current XEP) the CSI change nonzas can not be reliably tracked by means of XEP-0198. I can not see a real reason for how a stream resumption (i.e. due to a mobile/wifi change) should affect CSI state (which is related to the user interacting with the client). I think it would be much cleaner to bind the CSI state to the session (thus keeping it on session resumption), to use IQs for changing it (thus allowing XEP-0198 resumption/replay to properly take care of possible indication losses), and possibly also to require the server implementation to flush all "queued" data before the iq response. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
