[whatwg] HTML extension for system idle detection.

[timeless]

On Sun, Sep 13, 2009 at 7:08 PM, Jens Alfke<snej at google.com> wrote:
> 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.

The user is idle until the user navigates away from the page. You'll
probably still get a page navigation message. If you don't get one
after four hours, you can choose to decide that perhaps the client
disappeared.

> 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.

Sorry, design it without relying on help from browsers.

> 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.

I've only spent 3 years working for my present employer whose concern
is focussed on battery life. I know that's a small amount of time to
care about battery life, but i'm getting lots of push from people who
think their entire life has been spent worrying about customers'
batteries.

> Where's this sarcasm coming from?

No sarcasm. I would use <sarcasm> if I meant to include sarcasm.

> "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".

My product is likely to be one where people would want to use your
product, and the API will not work, which means you're going to have
to work around this broken API anyway. Designing it is a waste of your
time, since you're going to need to work around it anyway. You're
going to need to have a working design which doesn't rely on
cooperation from browsers. And telling web authors that they can rely
on browsers to cooperate is just going to result in mobile users where
communication products don't work, which is a great disservice to all
involved. Web Devs will assume that whatever API you settle on will be
universally available on "modern" browsers and that it will work. This
won't be the case.

> 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.)

The socket should be alive, and yes the browser should process the
pushed data, at least under certain circumstances. I'd expect js
wouldn't receive the data immediately. But using socket tricks should
enable you to classify the client as idle. If the user does switch
back to the browser the user should be able to see html in e.g. an
iframe if you happened to push data that way. You won't be able to use
a flash object to trigger a notification while the browser is in the
background. Support for <audio> was not in the last image I tested (it
might appear in an update, depending on approval well beyond my
control), but i'd assume we'd try to suppress it under the same
circumstances that we'd suppress plugins (although in an initial
update we might not).

> 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.

So. There's long been this disaster of "the web" and "the mobile web".
I'm working to bring a normal web browser to a mobile device, with the
hope that there would be only one web. If you add APIs which can't be
safely implemented on mobile devices then you help with the
continuation of the distinction between these two places, which is
terribly unfortunate. Now you could shift the blame and say that my
action of breaking the API is what is responsible for this, but the
thing is that I don't have a choice, short of power of the air (TM)
[it's funnier when you see devices which think they're charging
without any wires -- I have one of those here].

Personally, I don't like breaking features, and I really wish we
didn't have to break google apps, but battery life is critical for
mobile devices, such as mine.

> 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.

<sarcasm>
Ah yes, if we add this, does that mean you'll stop crashing Firefox by
unloading the Google Talk plugin while leaving your message window
handling code in the Firefox process?
</sarcasm>

The implementation of "idle" semantics on desktop processes has
historically been invasive and crashy. -- And in this area, I have
about 10 years of experience. Loading libraries into foreign processes
to track whether they are getting key or mouse input is indeed the
traditional long-established way to determine "idle" for
instant-messaging (I remember it from the original AIM).