[ticker-dev] Multiple presence clients for a single user

[David Arnold]

-->"Matthew" == Phillips, Matthew <Matthew.Phillips at dsto.defence.gov.au> writes:

  Matthew> There are 2 solutions to this that don't involve a third
  Matthew> party 1) my home 'online' client notices the contradiction
  Matthew> and sends a counter-update to set everyone straight or 2)
  Matthew> other clients notice the conflict between my two clients
  Matthew> and handle it by accepting the 'most available' status.

i'm wondering about a potential third method, which involves a few
other changes as well.  i've been trying to clarify the semantics in
my head, and i keep getting the urge to simplify ...

what if:

- there are only two status values: "available" or "unavailable".
  clients do not necessarily send an "unavailable" on exit, but
  perhaps a dialog box like "Set unavailable status?" is useful.

- in the case of multiple presence producers for a user, the one that
  changed most recently is always accepted.  a presence consumer can
  check the duration of the status they already have (if any) against
  the new status and ignore the update if it is older.

- presence *consumers* could downgrade their confidence in an status
  after a period during which they've seen no Presence-Info messages
  from a user.  this is similar in effect to 0.3.1's "unavailable?"

the only loss of functionality i can see is that mouse/key activity
cannot be used by the producer any longer.  one way to regain this
would be to optionally allow producers to downgrade themselves,
flagging their advertised info as potentially inaccurate.


from a user interface perspective, setting a status would now be a
two-part operation: available/unavailable plus the (optional?) message
text.  eg. unavailable + "in meeting until 3pm", or, available +
"dialed in from hotel", etc


this seems like a nicer semantics at the protocol layer to me.  what
do people think?




d