[JDEV] Status Notifications.

[Donovan Schulteis]

>> The roster is stored in a file on the server.  When the client conencts
to
>> the server, the server sends it back to the client.  The client keeps the
>> roster in memory, and periodically sends messages asking the server if
the
>> users are online.
>
>Expecting the clients to poll for people on your roster is going to
>become very expensive very quickly.  Presence indication is one of the
>most important features I think, and having built and used a system
>where I am notified *immediately* when someone arrives I find this vastly
>preferable.


Why not have the server store your roster list in your account (thus
allowing user/computer roaming), and when the user opens the client and
connects to their particular server, have the roster list downloaded from
the server to the client.  The server could then check to see who on that
roster is online at the time the connection is made and download that info
to the client (Either with the roster, or right after downloading it).
After that the server does no more checking.

When users connect to the server, a status is sent out to all persons in
their roster saying that the user has come online. This should be done by
the server at the same time that the roster is checked to see who is online
(above para).  After that, the client of each individual user could then
post all status messages to the server, AND all users listed in the roster.
That way, no traffic will be passed between clients and servers (after the
session loading) except when a user changes their own status or when actual
messages are being passed.  This way the client applications keep track of
who is online (and whatever other status needs), and relieves the server of
that responsibility.

In essence, the server would send the initial online message to the roster,
and then the client would receive all status messages from a buddys client,
and broadcast all further status messages to all buddies, ignoring any
bounced messages (if the client was to send to all buddies, instead of just
online buddies).   You have the server announce your presence and let you
know who is online, and then the client app accepts the status message
responsibilities from there.

The status messages would be sent just as any other instant message would be
sent, but the intended receiver would be the client, not the user.  The
client would then display the corresponding buddy status as necessary.
Any new buddies added during that session could be uploaded to the server at
the time of adding or when closing the session, updating the users
account/roster file.

This makes the client a little smarter than some have originally conceived
it to be, but I feel that this scheme is necessary to reduce the load on the
server greatly.  The server is already handling a great deal for each
individual user via multiple transports and message passing.  Give the
server a break  :)     Anyways, the idea is to get multiple, everyday ISPs
to adopt and implement this server, and they absolutely will not if it is
going to eat up processes and CPU time.

I dont know, what do you all think???
Deej