[Standards] XEP 85 "gone" and "inactive" state
seanegan at gmail.com
Fri Feb 16 01:38:42 UTC 2007
I'm currently implementing support for XEP 85's "gone" state in Gaim.
The definitions of the 'gone' and 'inactive' states both encourage a
client to enter these states after its own arbitrary timeouts. This no
longer conveys useful information about how the remote user is
interacting with the chat, but just arbitrary timeouts of varying
If I want a timeout of chat activity, I can do that locally. Just
count the amount of time since receiving a typing notification or
message. This way, I apply my definition of 'inactive' to all my
contacts, not the other users' unpredictable definitions.
I feel similarly about the 'gone' state. By having it defined as "your
friend has not interacted with you in some arbitrary amount of time or
the client has otherwise determined it wants you to know it's
considering itself inactive," it makes the state entirely ambiguous,
whereas it has the potential of being very useful.
I bring this up, because the MSN protocol does something similar. They
have a protocol message they send you when a one-on-one chat is ended.
For a while, reliably, their client sent this message when (and only
when) closing the chat window. A lot of people found it very useful to
know when the other person had closed the window. It puts a definite
end on a conversations that don't otherwise have one.
A newer version of the MSN client started sending this message when
the conversation window were closed OR after a 60 second timeout. Tons
of Gaim users complained that we were misreporting conversation
closes, and we had to remove the notification, as it no longer meant
anything useful. People still regularly and loudly complain that we
had to remove that wonderful feature (MSN users tend to have more
stalker-like personality quirks than most ;) ).
I strongly suggest removing the recommendations to change chat states
by arbitrary client-determined timeouts and changing them only to
reflect the user's interaction with the client:
active - the conversation window is focused
inactive - the conversation window is not not focused
gone - the conversation window is closed
composing and paused - keep the same
Obviously, clients that don't have conversation windows are free to
figure out how their interface maps to these states.
More information about the Standards