[ticker-dev] Multiple presence clients for a single us er

[David Arnold]

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

  Matthew> One key point is that the 'unavailable?' status is special
  Matthew> because it gets set automatically, and is not necessarily
  Matthew> triggered by a user. 

yep.

  Matthew> The other events are user-triggered and imply that the
  Matthew> person is really present - they are more 'positive' in that
  Matthew> respect.  However, even though accepting that the last
  Matthew> positive event is authoritative most of the time, it can be
  Matthew> broken fairly easily.  Say I'm moving back and forth
  Matthew> between two hosts and two clients, both of which
  Matthew> (correctly) list me as online.  I log out of one host,
  Matthew> setting my status to 'unavailable' as I do so. 

perhaps at this point your second client should adjust its idea of
your status?  since you are subscribed to your default group anyway,
you will see your own status notifications.  you just need to compare
the duration on the info, and update your internal idea of your state
accordingly?

clients would still need to display the newest value, cos the first
time the second client was used there'd be two different status
values, but after that, i think this might be better behaviour?

  Matthew> I also really want to have automatic 'unavailable?' as
  Matthew> standard in full-featured clients because we tend to forget
  Matthew> about setting our status.

i totally agree, but i was wondering about separating the concept of
availability and the, perhaps distinct, notion of the accuracy of
the status?

this could also allow the reverse of "unavailable?": if your status
says "unavailable" or "offline", but you've been sending ticker
messages (or some other activity), then your status could be marked as
possibly inaccurate, or effectively "available?"


  Matthew> I absolutely agree with keeping things simple, even at the
  Matthew> cost of losing some cool features. I'd say the spec is too
  Matthew> complex if an average hacker can't put together a halfway
  Matthew> useful presence implementation in an hour or two - I don't
  Matthew> think we've crossed that line yet.

i was just wondering if the status value was actually confusing two
things into a single value, and if separating them was better.

i don't think we need to lose any features.  and the automatic
downgrading of an online status if there's no activity is very
important.




d