W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

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

From: Doug Turner <dougt@mozilla.com>
Date: Thu, 10 May 2012 07:09:27 -0700 (PDT)
To: Marcos Caceres <w3c@marcosc.com>
Cc: Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <1902666619.567024.1336658967146.JavaMail.root@mozilla.com>
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.


----- 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
Received on Thursday, 10 May 2012 14:10:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC