- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Mon, 08 Sep 2014 19:40:26 +1000
- To: Rick Waldron <waldron.rick@gmail.com>, Tim Volodine <timvolodine@google.com>
- Cc: Tobie Langel <tobie.langel@gmail.com>, Marcos Caceres <marcos@marcosc.com>, Jonas Sicking <jonas@sicking.cc>, public-device-apis@w3.org, Anssi Kostiainen <anssi.kostiainen@intel.com>, "public-script-coord" <public-script-coord@w3.org>, Doug Turner <dougt@mozilla.com>, Domenic Denicola <domenic@domenicdenicola.com>, Anne van Kesteren <annevk@annevk.nl>
On Sat, 6 Sep 2014, at 00:59, Rick Waldron wrote:
> On Fri, Sep 5, 2014 at 10:18 AM, Tim Volodine <timvolodine@google.com>
> wrote:
>
> > "new Sensor.." does not sound natural in the context of sensors. There is
> > only one sensor per browser so it doesn't seem great to have multiple
> > objects for the same sensor.
> >
>
> This is an assumption that will lead to problems in the future: devices
> are
> already shipping with more than one of certain sensors, eg. proximity
> sensor. Also, 1st and 3rd party code must be allowed to create their own
> references of sensor objects with specified reading frequencies—those
> instances might be deriving their values from the same hardware source,
> but
> the frequency of value delivery must be allowed to be application-domain
> specific.
Tim's proposal as much as yours can take that into account, it only
require to use a Dictionary in Tim's proposal and have frequency as one
known property. It would then be extensible.
> Replace "register once" with "initialize an instance" and you have the
> Sensor design:
>
> // use default frequency, whatever that might be
> var light = new Sensor.AmbientLight();
>
> - or -
>
> // Specify a reading frequency in hz:
> var light = new Sensor.AmbientLight({
> frequency: 100
> });
>
> // ...
>
> // synchronous access to the value, but this is null right now
> // because the platform hasn't delivered a value yet...
> light.value;
I think the main difference between the two approaches is here: you
create the sensor object synchronously then set the value asynchronously
while Tim creates the object asynchronously, thus never expose an
undefined value. I think Tim's approach is better because having
undefined value would be fairly hard to handle for the developer. An
alternative would be to not expose a synchronous getter but instead do
something like:
```
var sensor = new Sensor({ [...] });
sensor.getValue().then(function(value) {
[...]
});
```
but that comes with the downside of requiring developers to keep track
of the current value themselves if they want to have a synchronous
access to it.
-- Mounir
Received on Monday, 8 September 2014 09:40:54 UTC