Hi, On Sun, Aug 21, 2011 at 7:24 PM, Kevin Smith <[email protected]> wrote: > I've been thinking about 296, and I'm still not happy with this > 'unlock on any presence even if it's irrelevant' thing. > > My preference is to say something like: > SHOULD (or MUST) unlock on a change of availability (available/FFC <> > Away/NA <> DND <> unavailable) and MAY unlock on other changes. > > The current text, and Matt's preference is: > MUST unlock on ... any <presence/> update. > > My argument is that unlocking on all presence will result in many > messages being sent to the bare JID unnecessarily, which creates a bad > experience for any users of multiple concurrent sessions and is > exasperated by the clients putting extra details into their presence .
I agree. A lot of <presence/> are sent by clients without being some kind of "away/unavailable" presence. If we were to "unlock" all the time, I think too that could make quite a bad user experience. > Matt's argument is that there exists a client that encourages people > to never change availability and that it's more important to address > this case. Though I agree that some clients may change too easily availability, I don't see the rationale behind *never* changing availability. It must be changed when it is needed, that's all. > My suggestion to resolve this is to add a 'requirements' section to > the start of XEP-0296 explaining what the objectives are. If we can > agree on objectives, the rest should flow out sensibly. So what should be the objectives? Also I have a general question about this XEP. What about threading? When we unlock a resource, are we supposed to make a new thread as though it was a new conversation (which it may not be)? Jehan
