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

RE: [Proximity] Proposal for addition field

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Mon, 19 Nov 2012 16:42:33 +0000
To: Marcos Caceres <w3c@marcosc.com>
CC: Anssi Kostiainen <anssi.kostiainen@nokia.com>, "DAP public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <84BCA539DD96614691177EDA3CE4FF0546C6D992@ORSMSX101.amr.corp.intel.com>

Yes, it is a bit of chicken/egg problem. However, we need some way to tell if there are multiple proximity sensors.  As for a Parking Sensor API, I don't think we want a API for any type of thing that comes about. As for Proximity API means the one for face-closeness detection on a mobile phone, I don't agree it just for mobile phone and face-closeness, we are seeing proximity sensors that are coming to the PC and tablet which has better range than just close to the face.


-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Monday, November 19, 2012 1:03 AM
To: Tran, Dzung D
Cc: Anssi Kostiainen; DAP public-device-apis@w3.org
Subject: Re: [Proximity] Proposal for addition field

On Monday, November 19, 2012 at 2:10 AM, Tran, Dzung D wrote:

> Hello,
> I don't particular have any example code for a web app, but here is my thought:
> If I have an optional field such as name and name = "front left" with near = true and name = "front center" with near = false and name = "front right" with near = false, then I know that the object is to the left of my screen. It is up to the OS to report the optional name parameter.

It's a bit of a chicken/egg problem, as initially there is unlikely to be any hardware that supports this out of the box - but as you elude to, tapping into the availability of sensors of existing devices (including cars) could be useful. 

However, I would be hesitant to adding your proposal to the API without actually fully understanding how these sensors actually work. There is a real risk of over-generalizing the API and that it in the end it proves impractical to make predictions about proximity for a set of applications. 

Consider parking sensors that you mentioned, which appear to be proximity sensors but also show qualities of distance sensing.  In this sense, I would rather just have a Parking Sensor API rather than a generic proximity sensor API. A Parking Sensor API would be smarter than a proximity sensor API, in that it would activate at the right moment. It would also alert the user when the sensor is not working; from wikipedia: "Most PDC systems have a fail-safe mode which detects a malfunction and alerts the driver that the system is not working and that he/she should not rely on it when reversing. Typically this is done with a long continuous tone as soon as reverse gear is engaged."

This is not to say we should build a Parking Sensor API, but that we should just say that the Proximity API means the one for face-closeness detection on a mobile phone and keep it strictly restricted to that. 
Received on Monday, 19 November 2012 16:43:25 UTC

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