[standards-jig] Re: [Foundation] Motion for Last Call - Chat State Notifications (JEP-0085)

David Waite mass at akuma.org
Fri Dec 5 02:07:49 CST 2003

On Dec 4, 2003, at 11:27 PM, Julian Missig wrote:
> I'm absolutely positive that if I sent "closed window" events to 
> people whenever I closed my windows, they would be offended. I close 
> windows all the time. It doesn't really make a difference. This is the 
> form of loss of privacy I'm talking about. No one's going to be 
> offended or know something important if they can see that I'm typing a 
> message to them. Depending on how the "closed window" event is 
> displayed to other users in their clients (which I have no control 
> over), it can seem rather offensive if they see that I closed their 
> window immediately after seeing a message. I think it will lead to a 
> lot more problems than it solves.

Speaking as someone who has used an official client for a legacy IM 
system which has "closed window" events, people do get offended. They 
don't seem to realize that I don't need to see their window until they 
decide to respond to my message. I've also used a client which notified 
the other user that the window was minimized or lost focus, and people 
think you are ignoring them.

It is a bit confusing whether Gone is optional or required, the spec 
	 1.  	When a client terminates a one-to-one chat session (e.g., when a 
user closes the chat session interface), it MUST generate a Gone event.

If I implement this in a chat client, Inactive will be triggered not on 
window closing or focus changes, but auto-away. Gone would be sent only 
on client close. This makes both a bit pointless (as the other user 
agent will get away or unavailable presence immediately afterward) but 
these are SHOULD requirements and not difficult to implement.

> Even if Chat State is accepted and such, I will not implement closed 
> window in any of my clients. Anyway, this whole closed window thing is 
> just a side rant to the bigger issue of Chat State vs. x:event 
> altogether. I don't want to completely get rid of and replace a 
> protocol which a lot of people are finally coming around to implement.

I know what you mean. The only real problem I have with x:event is that 
events are requested in response to a message, and not as an attribute 
of the conversation. Since everyone wants events on a chat, they assume 
the x:event protocol operates in a different manner than it really 
does, and thus send incorrect protocol. The real question is whether 
everyone will be willing to drop x:event and support a new standard, or 
if everyone will have to implement two standards for the forseeable 
future in order to give proper events.

-David Waite

More information about the Members mailing list