One of the most important features of any instant messaging system is the ability to monitor the presence, or on-line/off-line status, of users in your contact list. However, for some users, this is also one of the most annoying features. Many feel it is an invasion of privacy when strangers can silently monitor others' connecting habits. In order to maximize the benefits of presence monitoring while minimizing the loss of privacy, the presense-monitoring features of ODSIMS have been designed so that each user can have complete control over the degree to which others can monitor him.
Presence detection is achieved by querying other users' ONLINE property and by announcing, either solicited or unsolicited, your own ONLINE property whenever it changes. (Recall from "Querying Properties" that the ONLINE property is one of the reserved property names.) When your client first comes on-line, naturally the first thing you will want it to do is determine the presence of every user on your contact list. This is easily accomplished by polling each user's ONLINE property. Polled clients, whose users wish you to know, will then respond.
To find out who's going on- and off-line after you've already connected and performed your initial sweep, your client has two options. The first option, which is the most reliable, is to simply poll each user on your contact list on a periodic basis, say, once every minute. Unfortunately, this has the disadvantage of requiring a little bandwidth and processing, albeit not much, and it also does not allow you to learn immediately when a contact's presence has changed.
However, if your contact also lists you as a contact, his client will probably send you on- and off-line messages immediately after loggin on and immediately before logging off. In this case, the only time you would "miss out" is when your contact's connection is unexpectedly and abruptly terminated. When this happens, however, he is likely to immediately sign on again anyway. And since this case is rare, the fact that periodic polling will eventually detect it ought to be satisfactory.
Nevertheless, there is a second option. Your client can ask your contact's server to make you a monitor for that contact. If you are granted this status, your client will be notified whenever your contact's on-line status changes.
In order to protect your contact's privacy, however, thoughtfully-implemented servers will not register you as a monitor without the contact's prior approval. Servers implemented this way will not immediately register you when you request it, but instead will forward the request to your contact's client, who will then make the executive decision. If your contact is already on-line when you attempt to register, your contact's client will be asked at that moment if it approves of your registration. If your contact is off-line when you subscribe, your contact's server will simply buffer the request, and then ask your contact for approval after he has connected.
Your monitor registration with a contact's server is good for as long as your contact or your contact's server does not revoke it. However, both clients and servers can revoke your registration at any time for any reason. (This might happen automatically, for example, if a particular server implementation imposes a limits on the number of simultaneous monitors for a particular user, and that limit is exceeded. In this case, such a server might automatically cancel the older monitors. Another cause of unregistration might be that the server was rebooted.) For privacy-related reasons, your client will not be notified when your subscription is cancelled or refused. Hence, if your client relies on the subscription technique, it should renew its monitor subscriptions every time it goes on-line. Well-designed servers will anticipate this behavior and not allow you more than one simultaneous monitor subscription.
Even when your client is subscribed to a contact's presence information, however, that contact's clients will still be able to prevent you from knowing when it has gone on-line. The reason for this is that an active monitor subscription only guarantees you the following:
Thus, if you have a subscription, you might here that a client has gone off-line, even though you never knew he was on-line! Of course, your contact can prevent even this from happening also by cancelling your monitor before going off-line.
Because monitors can fail, a robust client will actually implement both presence detection techniques: it will subscribe as a monitor for every one of its contacts, in the hopes of always obtaining immediate information, and it will also perform periodic polling to back it up. Nevertheless, it is important to remember that presence detection is entirely in the hands of the party whose presence you are trying to detect, so it is possible that both techniques will fail anyway. There is nothing you can do about it. That is the ODSIMS way.