Re: [sensors] Dependency on [DOM] due to inheriting from EventTarget

A promise would only be useful to distinguish a sensor that has 
captured a
value from one that has not yet. I doubt that an interface that 
returns a
promise for the next captured value would be desirable, but if it is
desirable, is trivial to lift from any sane primitive.

Polling a sensor, a sentinel value of null or NaN should be fine to 
make
that distinction. It should be possible for composite sensors to treat
these as viral contagions. NaN is viral for free for the domain of 
numbers.

Providing an interface for counting interested consumers is a 
different
story. An interface that returns a promise for a sensor after it has
captured its first value would both express intent to consume and pass
ownership of the consumer. sensor.destroy() could communicate a loss 
of
interest.

On Thu, Jun 11, 2015 at 1:42 PM, Tobie Langel 
<notifications@github.com>
wrote:

> Take the one-time location request example from the existing spec 
(where a
> fresh location is required) and show how the Sensor API applies. 
(Yes - I
> know this is not a Promise-based API, but it can be adapted to be
> Promise-based).
>
> So I see three things which aren't immediately available here:
>
>    1. The ability to lookup a cached SensorReading without polling 
the
>    sensor, that doesn't seem like a big issue, and could be added in
 either
>    the Generic Sensor API itself or in the GeolocationSensor. 
Tracking it here
>    #47 <https://github.com/w3c/sensors/issues/47>.
>    2. The possibility to stop a SensorObserver before it is garbage
>    collected. In practice I'm not sure that's really needed 
(Johnny-Five
>    <https://github.com/rwaldron/johnny-five/wiki/Sensor> doesn't 
seem to
>    support it), nevertheless, filed an issue for it: #48
>    <https://github.com/w3c/sensors/issues/48>.
>    3. A convenience method to get a single SensorReading through a
>    Promise. This is actually both trivial to spec, implement and 
even
>    polyfill. It had been provided in a previous iteration of the 
spec, removed
>    in order to focus on solving lower-level primitives, but could be
 added
>    back, either in the Generic Sensor Spec itself, or in the 
Geolocation spec.
>    Tracking here: #49 <https://github.com/w3c/sensors/issues/49>.
>
> The Web developer community would benefit greatly from more 
consistency
> across the platform. So I sincerely hope we can resolve those issues
 and
> get the Geolocation Working Group fully onboard this effort.
>
> FWIW, you'll note a the new design I'm suggesting in #46
> <https://github.com/w3c/sensors/pull/46> borrows a lot of its aspect
> (notably the promise-based Sensors.matchAll sensor discovery method)
 from
> @timvolodine <https://github.com/timvolodine>'s initial proposal
> 
<https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf>
>
> Note that there are no DOM dependencies in the example as far as I 
can
> tell.
>
> No, but there's a dependency on navigator, thus on HTML, which 
frankly, is
> about as bad. ;)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/sensors/issues/21#issuecomment-111272750>.
>


-- 
GitHub Notif of comment by kriskowal
See https://github.com/w3c/sensors/issues/21#issuecomment-111277794

Received on Thursday, 11 June 2015 21:07:04 UTC