[whatwg] HTML extension for system idle detection.
snej at google.com
Sun Sep 13 09:08:39 PDT 2009
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
> 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.
More information about the whatwg