Presence is a common feature in many Instant Messaging applications. Nominally it reflects the status of user’s interaction with the computer that is running the application and has been used as an indication of the user’s readiness to interact with others. When it was originally conceived, most used a dial-up access and it is important to know whether a user is connected to the internet. Now most of us are always connected to the internet and have multiple devices connected at the same time. Consequently, the traditional Presence information is not very informative. For example, if I am busy on my computer and not used the standalone VoIP device is inactive, its Presence information will indicate that I am “away”. What good is this kind of Presence information and how could it become the “new dial-tone”?
Taking the above under consideration, EnThinnai does not provide “Presence” information as discerned by it; instead we allow the user to set the “Availability Status” information. The user can select one of the predefined values or can define a custom value. Additionally, the user can set the value globally applicable to all the buddies, or buddies belonging to a specific group or to a specific buddy. At first blush, requiring a user to manually set the value for Availability Status may look cumbersome or unwieldy; but this facilitates a future release to allow an authenticated third party to set the value. Indeed we envision EnThinnai or its agent to synthesize status information provided by multiple applications to a single value specific to a buddy, group or for the whole list. If you are familiar with iotum’s Relevance Engine, you know what I mean.
EnThinnai’s approach is also unique in the way the Availability information is notified to the buddies. Normally, Presence servers constantly update the status information to all the relevant parties. But we would like to avoid common centralized servers. One of our objectives has been to ensure that we realize all the features in a distributed fashion. Additionally, we feel that constant update places enormous load on the Presence servers. Since a user is interested in a buddy’s Presence information only occasionally, we feel that it is just as effective to query the information as and when it is required. If a user is interested in the change in the status, that can also be handled by registering for such an information with the buddy. Accordingly, in EnThinnai a user can get the Availability status information by hovering the mouse over the icon next to the buddy’s name. A future version will allow third party applications to retrieve the Availability Status information and also can register to get notified when the status changes.
Since the traditional Presence servers passively broadcast the Presence information, it is possible for a buddy to track a user over a period of time without that user’s knowledge. That is not possible in EnThinnai. Since the buddy has to query the status each time, EnThinnai can keep a log of such queries. In the current implementation, this log cn be accessed under the Syatem tab and Status Query Log sub-tab.
All in all, EnThinnai provides Availability status information using a different architecture that allows for distributed servers and protects the privacy of its users.
Many aspects of this feature is better articulated in an independently developed paper “New Presence” authored by Alec Saunders. Interestingly, Brough Turner in a follow-up suggested that we use “Availability” instead of New Presence. I hope that they feel that our implementation is in the right direction towards their stated objectives.
Posted in Uncategorized | 3 Comments
Leave a Reply
[…] Read the rest of this great post here […]
[…] Availability (vs. Presence) […]
[…] the level or type of connection”. This is what we have implemented in EnThinnai and we call it “Availability status”. Of course currently the process of combining multiple inputs is not automated, but that is our […]