On 7/21/11 9:23 AM, Matthew A. Miller wrote:
On Jul 21, 2011, at 08:39, Peter Saint-Andre wrote:
On 7/21/11 8:37 AM, Kevin Smith wrote:
On Thu, Jul 21, 2011 at 3:28 PM, Dave Cridland<[email protected]>
wrote:
On Wed Jul 20 23:00:33 2011, Matthew A. Miller wrote:
If there is only one resource online and the resource
updates presence but remains available.
This seems reasonable.
If the locked resource updates presence but changes
only<status/>.
I don't agree with this one. There are clients that, most
often at the explicit direction of their users, only
update<status/>.
Well, I think that's the point, and it's fine to stay locked.
If the change of any informational aspect of presence has to
cause unlocking, then you should be mandating unlocking on
several PEP events, too.
But we don't have to agree, here - just give the first case
above as a "for example", and note that it's always safe to
unlock.
I'll go further than this, I don't think we can claim it's a
best practice to unlock on text-only presence changes.
I'd suggest something along the lines of: SHOULD unlock on any
change of availability (e.g. changing from away to available) and
MAY unlock on other presence changes (e.g. where the text
changes).
Sounds right to me.
No, sorry, it's not right at all.
Like I said, there are a significant enough number of clients/users
that will use status and only status to indicate change in
availability. Whether that's right or not can be debated, but this
line **WILL** break behavior for a number of people, and there's no
sure fire way to detect such behaviors.
I realize that humans assign meaning to much of the XML character data
that is placed between the <status> tag and the </status> tag.
<status>On the phone</status>
<status>In a meeting</status>
Etc.
However, it strikes me as strange to assign programmatic meaning to
*anything* that's put in that spot.
<status>One the phone</status>
<status>Oops, I meant on the phone</status>
<status>In a meeting</status>
<status>Back at my desk!</status>
<status>Back at my desk and actually working :)</status>
<status>Bach: 2-Part Invention #1 In C, BWV 772, 1:29</status>
<status>Bach: 2-Part Invention #2 In C, BWV 772, 1:58</status>
<status>Bach: 2-Part Invention #3 In C, BWV 772, 1:14</status>
<status>Bach: 2-Part Invention #4 In C, BWV 772, 0:44</status>
Etc.
--
Peter Saint-Andre
https://stpeter.im/
