W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2015

Re: [sensors] When there are multiple sensors of a given type, how do we identify which one to instantiate?

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Sat, 06 Jun 2015 09:52:45 +0000
To: public-device-apis@w3.org
Message-ID: <issue_comment.created-109560854-1433584364-sysbot+gh@w3.org>
Thanks for the comments, people. A couple of thoughts:

1. It seems we're looking at two things here:
    1. a way to identify a physical sensor (Johnny-Five uses the pin 
address for that, WoT uses URI.)
    2. a discovery mechanism for the consumer of the API to locate the
 sensor.
    It might be that we end up voluntarily conflating the two and 
using the description of the sensor as a way to formally identify it 
(e.g. `new Sensor.Prox({ direction: "front", position: "top-right", 
internal: false })`), but I think making that conceptual distinction 
for now makes it easier to reason about the problem (well, at least, 
it does for me :).
    Thus, using a `Symbol` as identifier, as @davidmarkclements 
suggests above, doesn't seem totally inappropriate (for now). Again, 
whether we end up actually exposing that to the platform or not is 
TBD.

2. Whereas discovery (1.ii above) doesn't seem really critical for 
Johnny-Five and/or WoT to instantiate `Sensor` objects (you 
respectively know in which pin you've plugged the sensor, or where 
given a URL to the remote sensor you're planning to hear from), it's 
critical at the Web Platform level as you basically know nothing about
 the device you're running on. Thus a system as the one @rwaldron 
describes above seems essential.

3. Position in relation to a device (and in particular defining its 
natural orientation) has been extensively worked on by @marcoscaceres,
 @richtr and @mounirlamouri, notably in [The Screen Orientation 
API][1] and [Device Orientation][2] specs. Would be great to be able 
to reference their work as much as possible here.

4. Similarly would there be value in stealing some of the positioning 
stuff from CSS (e.g. z-index). I think not, but still throwing this 
out here.

5. Lastly, I want to make sure we don't go down the slippery slope of 
defining an ontology of positioning things in 3D. This is why I like 
@rwaldron's proposal so far, though I already know it's insufficient 
to describe proximity sensors on the back of a car (there are 
generally four of them). Maybe a combination of @rwaldron's 
keyword-based proposal combined with some less readable but more 
extensible system would work (e.g. nested arrays? <-- I have to thing 
about this more) would work?

[1]: https://w3c.github.io/screen-orientation/
[2]: 
http://w3c.github.io/deviceorientation/spec-source-orientation.html

-- 
GitHub Notif of comment by tobie
See https://github.com/w3c/sensors/issues/26#issuecomment-109560854
Received on Saturday, 6 June 2015 09:52:47 UTC

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