Re: [JDEV] Status Notifications.

[Tim MacKenzie <Tim.MacKenzie@fulcrum.com.au>]

On Tue, Jan 19, 1999 at 12:18:24AM -0800, Jason Diamond wrote:
> Ideally, users should be informed immediately when a buddy's status changes.

Definitely.

> Alice connects to her Jabber server. Bob is in her roster but not
> currently online. As soon as Alice connects, her server checks Bob's
> server for Bob's status. Since he isn't online, it's obvious that
> Alice wants to know as soon as he is. So Bob's server records Alice's
> address so that when Bob does come online, Alice can be instantly
> notified without her having to poll the server.
>[...]

Not bad, I don't think we can avoid polling remote servers when a user
comes online.

> her watch on Bob alive. There could also be a reasonable maximum
> number of watches allowed at one time. In this case, if the number of
> people watching Bob exceeded the allotted limit before Alice tried,
> Bob's server would respond telling Alice that she would have to
> unfortunately poll for Bob's status. Although, this places the burden
> on the client which I was hoping we could eliminate to begin with. Any
> ideas?

How about this. Each user has a roster of people she watches ([watch]) and
people who watch her ([watchers]). A status request to a remote server may
optionally include a request to be added to [watchers]. All status changes
would be reported to the [watchers], preferably by sending a single message
to each server within [watchers] (rather than each separate client - the
remote server could send it to each client).

This way a user knows who is watching and potentially has some control over
this. For example, a server may be setup so that requests to be added to
[watchers] get added to [pending-watchers] to be approved by the user, who
may approve them or add them to [disapproved-watchers] or [discard-users].
([discard-users] might be a roster containing users we never want to hear
from).

We now have a distributed database synchonisation problem - what if the
remote system is unavailable (or too slow) when a change is made. When a
server receives a status change for a user who is no longer interested
(ie has removed the watchee from [watch]) then it should return a message
to be removed from [watchers].

Tim