Yann, On Mon, 21 Dec 2009 15:02:08 +0100, Yann Le Boulanger <[email protected]> wrote:
[skipped] >> As a somewhat "safer" solution we might treat timeout value not as "time >> from the prefs set to prefs expiration", but as "time from the last >> message >> sent/received during conversation to prefs expiration" - then, having >> this >> value set to meaningfully large value will in most cases ensure that >> prefs >> cannot be removed while conversation is still active. > > Hmmm yep sounds nice, but I guess server won't send a new IQ saying > the new timeout at every message exchanged. So client won't know > exactly when they have to re-send the "hoho don't log this session" > IQ. Sure client could remember the value of the timeout server sent > the first time, and restart to count at each message, but server may > behave differently that client: chatstates message will restart > counter on server, but mybe not in clients ... Well, certainly I'm not that proficient enough in all existing XEPs/XMPP internals to claim it for sure, but I believe that all well-formed and not excluded due to subscriptions/privacy settings messages sent to client JID from the recipient JID must reach the client regardless of their type, no? (excluding transmission problems, of course) Anyway, even if some message restarts timer on server but due to some reason is not delivered to the client (so client does not restart its timer), the worst thing that happens is that client will send pref prolongation sooner than it was strictly necessary - hardly an issue at all considering that timeout should typically be comparably large, so it will not happen too often. > So maybe it's the best solution, but XEP have to be precise on what > makes the counter re-start. See above - I do not believe it's serious issue, though for sure we should be specific enough when specifying the way it should work ;-) If you believe this solution is OK (if not - please feel free to continue discussion/propose your own solution!) - shall we proceed with "formalizing" it so that we can propose to add it to the next XEP-136 version? If you feel like writing even rough sketch of the text that should be added to XEP-136, I think that would definitely help ;-) -- Good luck! Alexander
