Re: web intents version of sensor api

Sorry. "not what the group wants" is unfair. Some of us attended a face-to-face. All of us were invited. A significant number of people who couldn't attend in person availed themselves of a confidence bridge kindly provided by our hosts, Huawei. 

I'm on another trip this week and am busy redacting the minutes from last week's meeting. James and Greg have stuff to do but will hopefully send examples soon. 

Since I'm complaining about process violations, I'll take this moment to complain about the many messages sent to the list last week during the meeting.

The chairs made a request in advance of the meeting for materials relevant to the meeting be made available in advance. I believe that was mostly done. However, that should have also been an indication to people not attending the meeting that sending correspondence during or shortly after would not result in prompt responses and is not proper.

As a matter of process, consensus happens at meetings (call or face-to-face), it doesn't happen because people aren't available to respond to an email discussion while traveling. 

----- Original Message -----
From: Carr, Wayne [mailto:wayne.carr@intel.com]
Sent: Tuesday, March 27, 2012 01:46 PM
To: Doug Turner <dougt@mozilla.com>; Dave Raggett <dsr@w3.org>
Cc: public-device-apis@w3.org <public-device-apis@w3.org>
Subject: RE: web intents version of sensor api

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 27 March 2012 18:12:26 UTC