Re: [sensors] Device Proximity (was: Device light and proximity sensor)

Yes, this is the go-to example.

onLine basically returns internal state -- we are a browser, we kind of know when you're online.  In many cases we guess, but we can do it quickly.

With devices that might need to be powered on, having a sync API like navigator.proximity, might mean we need to do similar hackery -- or return undefined if the device hasn't powered on.  I am much more inclined to just let applications that want a property to add an event listener and set the prop themselves.

Doug


----- Original Message -----
From: "Marcos Caceres" <w3c@marcosc.com>
To: "Doug Turner" <dougt@mozilla.com>
Cc: "Robin Berjon" <robin@berjon.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Sent: Thursday, May 10, 2012 12:09:09 AM
Subject: Re: [sensors] Device Proximity (was: Device light and proximity  sensor)




On Wednesday, 9 May 2012 at 23:33, Doug Turner wrote:

> I don't like attributes - some people do. Attributes like this can be defined in the application logic. Lets defer?

I can understand that, but I suggested the attribute because this API closely resembles navigator.onLine - so it felt right not only from a use case perspective but also for consistency with another part of the platform. To go with Robin's naming suggestion navigator.proximity would wfm.  


-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 10 May 2012 14:10:04 UTC