Re: [JDEV] Status Notifications.

[Jason Diamond <sendangels@usa.net>]

Ideally, users should be informed immediately when a buddy's status changes.
Having the client or the server periodically poll another seems crude and
inefficient. Rosters should be stored on the server. As well as the access control
lists (perhaps we could come up with a more user friendly term) specifying who you
want to be notified of your status (if they even care--they put you in their
roster). Here's a simple proposal and example:

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. I think
this is reasonable. If you want to know a user's status, it's only fair that you
make your identity known. If Bob is popular, however, this might  place undue
stress on Bob's server. We could alleviate this by only recording users to notify
that Bob actually allows to be notified. There could also be some sort of timeout
mechanism. After the specified time, Alice will have to make another query to keep
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?

However it's implemented, I think that rosters should be handled in a module.
Since it is the server's resources that are being utilized, it should be a
configurable option whether or not the administrator wishes to support server side
rosters.

Jason Diamond