W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

RE: web intents version of sensor api

From: Carr, Wayne <wayne.carr@intel.com>
Date: Tue, 27 Mar 2012 17:46:08 +0000
To: Doug Turner <dougt@mozilla.com>, Dave Raggett <dsr@w3.org>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A3E306C63@ORSMSX101.amr.corp.intel.com>
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 Tuesday, 27 March 2012 17:46:44 UTC

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