Re: CfC to change Sensor approach, not progress current draft

On Wednesday, March 21, 2012 at 6:57 PM, Carr, Wayne wrote:

> It would be interesting to see the Web Intents approach to sensors discussed below. Could someone post a description of that?

I would also be extremely interested to see that.  

> With Web Intents, you could pass a message channel port to get a series of updates, a very common way of using sensors. But then you need to define a protocol for asking for watchpoints, for stopping them, for indicating how often you would like to get them, for setting values for notification when they're crossed. You may need to be able to define the sensor in more detail than a mime type. Those would all be the same for every sensor that produces a stream of data. You would not want to reproduce that in every single different spec for each particular sensor. You'd need a sensor spec containing much of what the current draft contains, wouldn't you?
I think you would at least need the current spec as a wrapper. So, even if Web Intents does it, it's probably too early to throw the baby out with the bathwater for the Sensor API.
> For the larger picture of sensors not in a device itself but on a local network of some kind, it isn't simply indicating you're interested in say wind speed/direction sensors and getting one back. It could be a dozen sensors in your yard and you'd like to be able to get data from all of them to summarize on a web page. Web Intents seems more set up for getting a single response. How do you get a set of sensors back to connect to and to know which one is which?

I was thinking the same thing… but I was thinking about my car's parking assist proximity sensors. My car has at least 8 sensors.    

--  
Marcos Caceres

Received on Wednesday, 21 March 2012 19:43:22 UTC