RE: When should a Device API be exposed? Re: Atmospheric pressure sensosr API

I assumed Marcos meant just the onxxx attribute on Window (not addEventListener which always is there).  All of these type specs add onxxx on Window.  For fingerprinting reasons, it seems you don't want it there just when there is a sensor.   So either always there for all of these type specs, or don't use that at all and just use addEventListener.  (this is about all of these, not this draft in particular).

>-----Original Message-----
>From: Doug Turner [mailto:doug.turner@gmail.com]
>Sent: Friday, September 07, 2012 9:43 AM
>To: Marcos Caceres
>Cc: Tran, Dzung D; public-device-apis@w3.org
>Subject: Re: When should a Device API be exposed? Re: Atmospheric pressure
>sensosr API
>
>We have been exposing many of these APIs as events.  You can always register
>for non-existing events, right?
>
>.addEventListener("ILoveCookies", handler, false);
>
>
>So, with this approach, you will not be able to determine if there is any hardware
>backing the API.  I think the fallback is that if you don't get a result in some
>reasonable amount of time, you assume that there isn't any hw backing the API.
>
>Doug
>
>
>On Fri, Sep 7, 2012 at 5:18 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>> Hi,
>> Sorry.. dumb question, but I can't ever remember the answer: if a hardware (or
>similar) capability is not available on the host device, should the API be exposed
>by the UA? I thought I had read somewhere (HTML spec? WebIDL?) that the UA
>should not expose the API when the capability is not available.
>>
>> I'm asking because I saw the following in the Atmospheric API proposal: "Not all
>devices contain a barometer, and when there is no barometer, this API is still
>exposed to the scripting environment but it does nothing".
>>
>> Kind regards,
>> Marcos
>> --
>> Marcos Caceres
>> http://datadriven.com.au

>>
>>
>> On Thursday, 6 September 2012 at 23:30, Tran, Dzung D wrote:
>>
>>> Hello,
>>>
>>> I quickly put together a draft for the atmospheric pressure sensor,
>>> since I saw that this sensor was available in my Nexus Galaxy phone.
>>> Also, the use cases for this sensor are documented in the spec:
>>> http://dvcs.w3.org/hg/dap/raw-file/tip/pressure/Overview.html

>>>
>>> Thanks
>>> Dzung Tran
>>>
>>>
>>> -----Original Message-----
>>> From: Marcos Caceres [mailto:w3c@marcosc.com]
>>> Sent: Friday, August 24, 2012 4:55 AM
>>> To: Doug Turner
>>> Cc: Frederick.Hirsch@nokia.com (mailto:Frederick.Hirsch@nokia.com);
>>> public-device-apis@w3.org (mailto:public-device-apis@w3.org)
>>> Subject: Re: CfC: Progress Ambient Temperature and Ambient Humidity
>>> Events drafts in DAP, publish FPWD of each
>>>
>>>
>>>
>>> On 24 Aug 2012, at 03:13, Doug Turner <doug.turner@gmail.com
>(mailto:doug.turner@gmail.com)> wrote:
>>>
>>> > Is either the Ambient Temperature Events or Ambient Humidity Events
>>> > implementable at this point?
>>>
>>>
>>>
>>> Not that I know of. It could be piggy-backed on Android, but...
>>>
>>> > I looked at various popular
>>> > phones/devices and none come with capable sensors. Did I miss one?
>>>
>>>
>>>
>>> I also looked but could not find any.
>>>
>>> >
>>> > On Wed, Aug 22, 2012 at 8:35 AM, <Frederick.Hirsch@nokia.com
>(mailto:Frederick.Hirsch@nokia.com)> wrote:
>>> > > This is a Call for Consensus (CfC) to progress the Ambient Temperature
>Events and Ambient Humidity Events drafts in DAP and to also publish a FPWD of
>each when the CfC completes. It includes the following resolutions:
>>> > >
>>> > > 1. RESOLUTION: progress the Ambient Temperature Events and
>>> > > Ambient Humidity Events drafts in DAP
>>> > >
>>> > > 2. RESOLUTION: publish FPWD of Ambient Temperature Events, having
>>> > > shortname 'temperature',
>>> > > http://dvcs.w3.org/hg/dap/raw-file/tip/temperature/Overview.html

>>> > >
>>> > > 3. RESOLUTION: publish FPWD of Ambient Humidity Events, having
>>> > > shortname 'humidity',
>>> > > http://dvcs.w3.org/hg/dap/raw-file/tip/humidity/Overview.html

>>> > >
>>> > > Please review the current drafts and make the comments you believe you
>need to make before next week, at which point we'll make the decision to publish
>or not.
>>> > >
>>> > > Note that there is no requirement on FPWDs to be perfect — if they were
>perfect we'd go straight to LC. They need to be good for broader review, and
>reasonably feature-complete.
>>> > >
>>> > > Where CfCs are concerned, silence is considered to be assent, but positive
>support is preferred (even if simply with a +1).
>>> > >
>>> > > regards, Frederick
>>> > >
>>> > > Frederick Hirsch, Nokia
>>> > > Co-Chair, W3C DAP Working Group
>>> > >
>>> > > For tracker this should complete ACTION-570
>>
>>
>>

Received on Saturday, 8 September 2012 17:59:33 UTC