Re: [sensors] Relation to REST APIs and W3C Web of Things activities

Thinking about this more, I feel like remote sensors are good 
candidates for using the Generic Sensor API, but that not all "things"
 are. For example, I don't see how a lightbulb fits that category.

If IoT APIs were to rely on the Generic Sensor API it would need to 
devise similar primitives for other "things," (e.g. for actuators) 
which would mirror the Generic Sensor API.

With that model in mind, the initial metadata-carrying handshake 
serves to asynchronously determine what kind of "thing" we're 
communicating with and instantiate the appropriate object. Is it a 
remote thermometer? We'd instantiate a `Sensor.Temperature` instance 
and pass it the the URL or WebSocket connection it must rely on to 
stream data events. It's a lock? We create instead a new instance of 
`Actuator.Lock`. It's a new kind of pressure sensor the platform knows
 nothing about? That's OK too, the metadata tells us which library to 
load so as to manage the raw data and massage it into something more 
palatable, etc.

In summary, the Sensor object would be a low level object (inheriting 
from EventTarget) that reflects the change in value(s) of a sensor at 
regular time intervals. It could reflect the values of a sensor 
supported by the platform or of an unsupported one (in which case 
connection means and a process to make sense of the sensor's output 
would need to be provided e.g. a JS library of some sort). Sensors 
could be local or remote. In the latter case, a mean of connection 
would again need be passed to the sensor object.

Would such a low-level primitive fit your use cases and requirements? 

-- 
GitHub Notif of comment by tobie
See https://github.com/w3c/sensors/issues/18#issuecomment-103237330

Received on Monday, 18 May 2015 22:37:12 UTC