W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] HTML extension for system idle detection.

From: timeless <timeless@gmail.com>
Date: Sun, 13 Sep 2009 16:56:16 +0300
Message-ID: <26b395e60909130656y54b8ac76ibed0ce74d8ec5e67@mail.gmail.com>
On Tue, Sep 8, 2009 at 9:58 PM, Jens Alfke<snej at google.com> wrote:
> The first statement implies that a web-app on your platform cannot implement
> the algorithm you recommend.

Sure it can. The user is effectively idle, in that they are not using
your web application <period>.

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 and you *must* rely on the server to
figure this out.

This  is functionally equivalent to someone having three devices, a
Mobile Phone (TM), an Internet Tablet Device (TM), and a Pocket DVD
Player (TM). In this case, the user stops using their Internet Tablet
in favor of their Pocket DVD Player (TM) to watch the movie or their
Mobile Phone (TM) for their two hour long w3 conference call. In all
these cases, the web browser and its hosted app is idle and that's
what the web server should conclude. The user's focus is not on the
browser and in fact, the browser is effectively dead.

> The web-app would need to send a series of
> 'ping' messages to the server every n minutes as long as the user is using
> the device, so the server won't set the status to 'idle'. But if the user's
> doing something else on the device other than using that page, its JS won't
> run, so its timeout doesn't get a chance to send the message.

Yes, because the web browser is idle which is the conclusion you must reach

> Basically, it sounds like a web-app on the n900 cannot make decisions based
> on overall idle time at all, only on idle time within its app.

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.

> So it wouldn't make sense for the platform to implement this API.

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.


In short, what I'm saying is that I'm objecting to a procedure for
system idle, the concept is broken and it won't work, and i'll be
forced to break it the day after it's integrated into Gecko and then
people will wonder why it doesn't work.

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. Perhaps we're on the same
page, in which case, great :).
Received on Sunday, 13 September 2009 06:56:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC