[whatwg] HTML extension for system idle detection.

On Sep 13, 2009, at 6:56 AM, timeless wrote:

> That they might be watching a 2 hour long movie with the device or on
> a 2 hour W3 conference call is irrelevant, they are idle for the
> purpose of your web application

That is not what "idle" means to an instant-messaging/presence service  
like AIM or Jabber. The "idle" state means the user is not at the  
device, to the best of its knowledge. If the user is capable of  
receiving messages but does not want to be interrupted, that's called  
"away" or "busy". If the user is not able to receive messages at all,  
s/he's effectively offline.

Given that we are designing this API primarily for the benefit of IM  
apps, we need to end up with something that matches their semantics.

Trust me on this. I spent several years immersed in IM protocols and  
was the tech lead on the first release of Apple's iChat client.

> Yes, because for some insane reason we decided battery life was more
> important than Google Web Application (TM) support. I'm actually quite
> sorry about this, but it was a management decision.

Where's this sarcasm coming from? It seems rather unprofessional in  
this context. It's hard enough to design protocols by email when  
everyone's showing goodwill; don't gratuitously make it even harder  
for us.

> I'm not sure which API you're talking about. We ship Gecko + our API
> breaks. We're a non trivial mobile phone vendor. We're likely to
> continue to add similar breaks.

"HTML extension for system idle detection" is the API under  
discussion. My point is that it is likely not feasible for your  
platform to support this extension, given what it's capable of  
providing. That doesn't mean the extension is somehow "broken".

If the device doesn't implement sufficient multitasking to allow the  
browser to remain active in the background, then from an IM  
perspective the state the browser goes into is "offline", not "idle",  
since the browser's incapable of receiving messages. (Or is it? On  
further thought, I'm unclear on this. You describe the socket  
remaining open, so if the server were to send data over it, would the  
browser wake up and allow the app to respond to it? If so, then it  
actually is an 'idle' state.)

> This is implementation feedback explaining why the feature doesn't
> work, isn't practical, shouldn't be implemented, and more importantly
> how there is a solution available today which works TODAY without
> requiring the addition of this broken API.

I'm fine with those statements as long as you append "...on our  
specific platform" to each one. In the general case, however,  
especially on non-mobile platforms, they aren't true at all. In  
particular, the solution you describe is absolutely not a solution to  
the problem under discussion here, for any general purpose OS, because  
it does not match the long-established semantics of "idle" in instant- 
messaging/presence protocols, i.e. no detectable user interaction with  
the computer as a whole.

?Jens

Received on Sunday, 13 September 2009 09:08:39 UTC