- From: Rick Waldron via GitHub <sysbot+gh@w3.org>
- Date: Sun, 06 Mar 2016 19:19:22 +0000
- To: public-device-apis@w3.org
IIRC Solution 3 is part of my original proposal? I still think that's the ideal path: The API surface itself describes a clear demarcation between capabilities - instance provides your "polling" mechanism; one can intuit that initializing an object makes sense for a thing that's long living - static method provides the one-shot mechanism; "I just need to know [where the user is, what the temperature is, what the surrounding light condition is], one time and that doesn't require making an instance that will just be thrown away." -------------------------- RE: Solution 3, Con 1 > Event-based solution a bit more wordy than solution one above. How so? ```js let sensor = new Geolocation({ accuracy: "high" }); sensor.ondata = event => displayMap(event.data.coords); ``` That could be either Solution 1 or 3. RE: Solution 3, Con 2 > Won't let you pass around sensor instances without triggering hardware activity (which means that a future discovery API might need to rely on lightweight sensor-like objects instead of just using those). If the processor and sensor hub are powered, then hardware is already active. Also, not all use cases will specifically register events in order to access the sensor data: ```js let sensor = new Sensor({ accuracy: "high" }); requestAnimationFrame(function frame() { console.log(sensor.values); requestAnimationFrame(frame); }); ``` Initialization (`new Sensor(...)`) should be the only "opt-in" necessary to create an active sensor. RE: Solution 3, Con 3 > Feels sort of awkward when you have multiple sensors of a same type That doesn't look awkward to me, it looks clean and completely understandable. Also, I like that `read(...)` accepts similar options as the class constructor, that's valuable. What I would suggest is that you hold firmly on that design choice and let the built-ins work for you: ```js // ... Promise.all([ Proximity.read({ position: "bottom-left", direction: "rear" }), Proximity.read({ position: "top-middle", direction: "front" }), ]).then(proximities => { proximities.forEach(prox => { console.log( tags.stripIndent` Position: ${prox.position} Direction: ${prox.direction} Distance: ${prox.distance}cm ---------------------------- ` ); }) }); ``` Would result in something like... ``` Position: bottom-left Direction: rear Distance: 1cm ---------------------------- Position: top-middle Direction: front Distance: 12cm ---------------------------- ``` (complete simulation [here](https://gist.github.com/rwaldron/cf99b0bedb2e53c9a264)) ----------------- Re: Solution 2, (alleged) Pro 1 > ... If startObserving() hasn't been called, no events are fired. I do not see this as a "pro". As I stated above, initialization should be the only "opt-in" for an active sensor. If there is a need for `pause` and `resume` (which there may very well be) then we should consider those, but separately from this issue. -- GitHub Notification of comment by rwaldron Please view or discuss this issue at https://github.com/w3c/sensors/issues/88#issuecomment-192967025 using your GitHub account
Received on Sunday, 6 March 2016 19:19:24 UTC