Re: [jdev] JEP-0085 clarification
Quoting Travis Shirk [EMAIL PROTECTED]: Imagine the following scenario: 1) UserA sends question to UserB 2) UserB receives message and consults browser/editor/etc. to answer question. 3) UserB sends answer to UserA At no point during this exchange does UserB stop paying attention to the chat, so no, I don't think that an inactive/ should be sent. Really, it depends whether they can see the chat window. If they can't see the text appearing in the window, then they can't possibly be paying attention to the *chat*. They're paying attention to the other program, whether or not they're in that other program because of the chat. On the other hand, if you're like me and have three chat windows and the browser visible at the same time, it should be considered that all *three* windows are being paid attention to. For completeness, if step #2 involved UserB getting distracted and surfing the web for the next N+1 seconds an inactive/ MUST be sent. That's cool, let's just insert some mind probes into the person then, so that we can tell the difference between 60 seconds of research and 30 seconds of research plus 30 seconds of distraction. Actually, eye tracking software might be enough, if there is already a webcam connected... Meanwhile, using window coverage to determine whether attention is being paid feels like a much more sensible approach. If the text is visible, you're paying attention. If it isn't, you're not. Approximate to mean the window instead of the text to make implementation easier. :-) TX This message was sent using IMP, the Internet Messaging Program.
Re: [jdev] JEP-0085 clarification
Quoting Travis Shirk [EMAIL PROTECTED]: For completeness, if step #2 involved UserB getting distracted and surfing the web for the next N+1 seconds an inactive/ MUST be sent. This was just an example of a more sane implementation, not an algorithm that I think the JEP should require clients to implement. Having said that, I think requiring at least this is better then requiring less (e.g., a simple focus change). Unnecessary inactive/active packets is annoying to the receiver, not to mention unfriendly to the network. On Wed, 2005-09-07 at 11:17 +1000, Trejkaz wrote: Meanwhile, using window coverage to determine whether attention is being paid feels like a much more sensible approach. If the text is visible, you're paying attention. If it isn't, you're not. Approximate to mean the window instead of the text to make implementation easier. :-) Now this is what I'm talking about! -travis
Re: [jdev] JEP-0085 clarification
Travis Shirk wrote: JEP-0085: Chat State Notifications[1] states that inactive/ should be sent when: User does not interact with the chat interface for an intermediate period of time (e.g., 30 seconds), minimizes the chat interface, or starts interacting with another chat interface or application. The phrase starts interacting with another chat interface or application simply restates (only with more ambiguity) User does not interact with the chat interface for an intermediate period of time (e.g., 30 seconds). Ambiguity is bad. Well, at least in protocol specifications. :-) Is there anyone out there that supports sending inactive/ every time a window loses focus? (/me is cocked and ready :)), and if not, can we get an update to the JEP that stresses that this is not the intention. The trigger descriptions in JEP-0085 are intended to provide guidelines, not hard and fast rules. That said, now that you've pointed it out I agree that the guidelines regarding inactive/ are ambiguous. What matters most here is whether the user *has* interacted with the chat interface over the last x seconds. It is probably unwarranted to assume that the user *will not* interact with the chat interface over the next x seconds simply because he or she has minimized the chat interface or switched focus to another chat interface or application. (However, assuming that the user is gone because he or she has terminated the interface may be more warranted.) This kind of predictive notification could lead to many false alarms so I think we need to discourage it by tightening up the trigger language for inactive/ (and possibly also gone/). Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
