Multiple presence clients for a single user

[Phillips, Matthew]

Hi all,

I've been doing some cogitating on how to support multiple clients for the
same person without (a) bloating the protocol and (b) without needing
centralised state.

[Martin, sorry for skipping a more personal response, but I think this
addresses some of your thoughts]

Scenario: I run a presence client at work and then go home and run another:
both will initially respond that I am online.  The work client then decides
that I am 'unavailable?' and emits an update, thus making it look like I am
no longer available.

There are 2 solutions to this that don't involve a third party 1) my home
'online' client notices the contradiction and sends a counter-update to set
everyone straight or 2) other clients notice the conflict between my two
clients and handle it by accepting the 'most available' status.   I don't
like 1 because it's messy and would result in status flicking from online to
unavailable to online.  However, option 2 requires that other clients can
tell my two clients apart, since if they can't, they cannot tell that the
'unavailable?' came from a different source to the 'online'.

I have had a think about how a client would implement 2 and it does not seem
hard _if_ there were a 'Client-ID' field on Presence-Info.  Client-ID would
by any random string that remains constant for a given client over a given
session.  Other clients would maintain a registry of User's (user at domain),
each entry of which has an associated list of Presence-Info's, indexed by
Client-ID.  When a new info comes in, the client updates the info for that
User/Client-ID and the client then selects the 'most available' info from
the list and displays that.  Quick-and-dirty clients that don't want to muck
around with this could just show the list of Presence-Info's sorted by User
and then Status.

There are a few other issues, such as clients that crash and don't send an
'offline', but these are solvable.

Comments?