Re: web intents version of sensor api

One item I've not seen discussed: buffers.

There are some cases with low-powered (speed and battery) devices where an event will hold a buffer containing a large set of sensor input in binary form. Consider that a single event sent every 100ms may contain hundreds of sensor readings for that time period.

I've rarely seen the method used. 

-Charles



On Apr 1, 2012, at 7:07 PM, "Tran, Dzung D" <dzung.d.tran@intel.com> wrote:

> Thanks for the wiki. I am planning to take a look at all the discussions and probably will do another edit of the spec this coming week.
> 
> Tran
> 
> -----Original Message-----
> From: SULLIVAN, BRYAN L [mailto:bs3131@att.com] 
> Sent: Friday, March 30, 2012 1:48 PM
> To: Frederick.Hirsch@nokia.com; Carr, Wayne
> Cc: dougt@mozilla.com; dsr@w3.org; public-device-apis@w3.org
> Subject: RE: web intents version of sensor api
> 
> To help move this forward and provide a forum for the discussion, I have created a template wiki page: http://www.w3.org/2009/dap/wiki/Sensor_Issues
> 
> Thanks,
> Bryan Sullivan 
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
> Sent: Friday, March 30, 2012 12:38 PM
> To: wayne.carr@intel.com
> Cc: Frederick.Hirsch@nokia.com; dougt@mozilla.com; dsr@w3.org; public-device-apis@w3.org
> Subject: Re: web intents version of sensor api
> 
> I agree the conversation is useful and appropriate given the CfC - however  this is a post-F2F discussion, as discussion at the F2F was based on material shared before the F2F.
> 
> I don't think we should dismiss Dave's architectural point - it is hard to say how fast the environment the results of our work will be in, and for how long.
> 
> Charles makes a good point about abstractions layers as did Bryan about approaches.
> 
> I'd rather not focus now on how we publish, but get straight what we should do next technically.
> 
> My personal understanding is  that there is enough concern in the WG not to pursue an approach of defining a generic sensor API that allows use for arbitrary to be defined sensors,  due to concern about the implications for specific sensors. I generally agree with Wayne that it might not make sense to replicate commonality across a number of specs.
> 
> I think it would be useful to 
> 
> 1. concretely understand the aspects across various sensors that would vary, the concerns that are relevant that are sensor specific
> 
> 2. agree on general approach related to thresholds etc that might be common to sensors , concerns about battery use, etc
> 
> 3. understand on how to address local and remote sensors uniformly (web intents).
> 
> 4. Review forthcoming material from Josh and others
> 
> Other suggestions are welcome. As co-chair I think the list discussion is useful and there is no need to shut it down at this point.
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia
> Co-Chair, W3C DAP Working Group
> 
> 
> 
> 
> On Mar 27, 2012, at 1:46 PM, ext Carr, Wayne wrote:
> 
>> As Bryan implied, it can be seen as 2 separate problems.  A very simple API for common device sensors (where we know what they are).  A Web Intents solution to comprehend local network or farther afield sensors.
>> 
>> In response to a previous email.  I think  the back and forth has been useful.  It seems fairly clear web intents for these device sensors is not what the WG wants.  The question is whether it is one direct api spec (without discovery) or 7 similar ones.  I think that's progress/
>> 
>>> -----Original Message-----
>>> From: Doug Turner [mailto:dougt@mozilla.com]
>>> Sent: Tuesday, March 27, 2012 1:17 AM
>>> To: Dave Raggett
>>> Cc: public-device-apis@w3.org
>>> Subject: Re: web intents version of sensor api
>>> 
>>> 
>>>> This discussion seems to be missing out on how users select sensors
>>>> according to their location. I don't think we should restrict
>>>> ourselves to sensors on the same device as the browser.
>>> 
>>> I completely disagree.
>>> 
>>> 
>>>> For example, temperature
>>>> sensors which could be located in different rooms in your home. The
>>>> user could pick between them without the need for any changes to the
>>>> web application itself.
>>> 
>>> Okay, lets come back to 2012 for a second. ;)  The use case you are talking about
>>> doesn't exist.  There are so few homes on this planet that have temperature
>>> sensors that are accessible over a network to justify *any* discussion about
>>> standardize a generic way to address them.  This is runaway engineering.
>>> 
>>> We need to focus on exactly the mission of this group - "to create client-side APIs
>>> that enable the development of Web Applications and Web Widgets that interact
>>> with devices services such as Calendar, Contacts, Camera, etc.".  Lets focus on
>>> the needs of today as fast as we can and leave the "we can solve the worlds
>>> problems with WebIntents" for another time.
>>> 
>>>> As Josh points out, it would even be possible for the user to pick a
>>>> weather site that provides local temperature as a service.
>>> 
>>> Yup -- or just use an XHR.... like developers do now.  Or let some smart javascript
>>> hacker build a jQuery like library around the simple clean interface we make for
>>> temperature and extend it to also do XHR's to weather.com.
>>> 
>>> 
>>>> This has obvious benefits for privacy, as the web app doesn't get to
>>>> fingerprint users in terms of the sensors available.
>>> 
>>> It isn't that clear to me that is true. I also think you are muddying the waters.
>>> WebIntents don't make anything more or less safer for the user.
>>> 
>>>> Different kinds of sensors will have different implications for
>>>> privacy, and this suggests that we need to look at the use cases and
>>>> privacy implications for each kind of sensor. The work on using the
>>>> accelerometer to figure out what some is typing on a nearby keyboard,
>>>> or to detect when someone is walking. The ability for a noise sensor
>>>> to monitor when people are talking. We can brainstorm ideas and then
>>>> work out the implications for each kind of sensor.
>>> 
>>> 
>>> That sounds fine.  No one is arguing against that.
>>> 
>>> 
>>> Doug
> 
> 
> 
>

Received on Monday, 2 April 2012 02:29:15 UTC