[![W3C][1]][2]

# Device APIs Working Group Teleconference

## 09 May 2012

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Anssi_Kostiainen, Bryan_Sullivan, Cathy, Claes_Nilsson, Clarke_Stevens,
Deepanshu_Gautam, Diana_Cheng, Dsr, Dzung_Tran, Frederick_Hirsch, Josh_Soref,
Jungkee_Song, Laszlo_Gombos, Milan_Patel, Niklas_Widell, Samarth_V_Deo

Regrets

    Robin_Berjon

Chair

    Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Administrative][6]

    2. [Minutes Approval][7]

    3. [F2F Planning][8]

    4. [Sensors, Device, Light, Proximity][9]

    5. [Gallery][10]

    6. [SLAPI][11]

    7. [Feature Permissions][12]

    8. [Proximity][13]

    9. [AOB][14]

  * [Summary of Action Items][15]

* * *

<trackbot> Date: 09 May 2012

<scribe> Scribe: Josh_Soref

### Administrative

<fjh> [CR of Battery API published][16]

<fjh> [CR of Vibration API published][17]

fjh: thanks AnssiK, mounir

<fjh> [NFC WG chartering][18]

fjh: that's a message from dsr about NFC WG chartering

dsr: darobin and I have been working on System Level APIs charter

... we hope to have both charters up for review at the same time

... we need to fill in some dates in them to complete them

<fjh> [System Level Charter email][19]

fjh: do you have a deadline for them?

dsr: we'd like to get them done ASAP

fjh: I noticed NFC was mentioned in the System Level API

... I'm not sure that's appropriate

dsr: AC review is a good way to get feedback

... [ it can be removed then ]

<fjh> DAP Welcome to new members

<fjh> [Yosuke Funahashi, Doug Turner, Mahesh Kulkarni, Cuihtlauac Alvarado,
and Milan Patel][20]

<fjh> [Paul Liu Feng and Eduardo Fullea Carrera][21]

fjh: if you're new and want to introduce yourself, now is a good time

... but please also introduce yourselves on the list

### Minutes Approval

<fjh> Approve minutes from 25 April

<fjh> [Minutes from 25 April][22]

**RESOLUTION: minutes from 25 April are approved**

### F2F Planning

fjh: we have agreed for July 10-12

... we have offers from Nokia, Burlington

... and Vodafone, Dusseldorf, Germany

... I think we need to decide this week

<fjh> Next F2F 10-12 July 2012.

<fjh> Hosting offers (1) Burlington MA US (Nokia), (2) Dusseldorf, Germany
(Vodafone)

Josh_Soref: I was hoping we'd have a decision today :)

milan: being in Europe, I have a preference for Europe

Cathy: I'll note that TPAC is in Europe as well

... so it might be better to do it in US

fjh: We could do a survey

... darobin is ok either way

dsr: unless you hear strong objections

... it's up to you

fjh: proposed resolution to meet in burlington

nwidell: I'd prefer to have it in Europe

... it's the middle of vacations in Scandinavia

... so it's easier to get to

fjh: I think it'll be easier for some to get to Burlington

**RESOLUTION: F2F meeting July 10-12 in Burlington**

fjh: thanks dsr

... sorry nwidell

... I understand your concern

### Sensors, Device, Light, Proximity

fjh: AnssiK, I know you put together a draft

<fjh> [Device light and proximity sensor][23]

fjh: I know wonsuk updated his draft

... talking about proximity

<dtran> I have updated the Sensor API also

fjh: I noticed it's essentially the same as wonsuk's

... your draft seems more detailed than wonsuk's

... I don't understand min/max

... it seems like it'd be constant for a sensor

dtran: I was editing sensor API for a while

... I updated the API to have the same signature as dougt suggested

... min/max are pretty much constant for all sensors

... I don't know if we could make them separate attributes

... now you get the same value every time

... min/max are constant

fjh: min/max are constant for a given sensor, which is what I'd expect

... I noticed that AnssiK supported separate specs

... it's also easier for testing and moving specs forward

... to have separate specs

... packaging concerns as AnssiK mentioned, we can pull out later

dtran: the sensor spec says it's optional to implement sensors

... it's up to a UA to decide what to implement

... we could rip them out one by one

... I just don't like having lots of specs that look all the same

fjh: I understand

... but having optional things

... getting interop is harder

... editorial task of one/two docs can be handled later

... we need to focus on implementations now

AnssiK: I think fjh has said what I wanted to say

... small self contained features/specs progress on REC track better

... some things that are common to all sensors

... it's much easier to work on the right design with one sensor first

... and then progress with others

... I think security/privacy considerations should be taken seriously for all
sensors

... if we work on sensors separately, the likely that security/privacy is
properly scrutinized increases

... I'm happy to work with others to make it happen properly

... I want to get other implementers interested

... an all in one spec may scare away implementers

... I'd like to ask for an opinion

... all-in-one, or one-by-one

<AnssiK> [[sensors] Device Proximity (was: Device light and proximity
sensor)][24]

AnssiK: in my mail, I had my arguments

... it would be better to reply to my mail on the list

... thanks

bryan: those are all sensible arguments

... I had concerns in the past with documentation in multiple specs

... on technical aspect

... maybe I can send to the list again

... does the group think it's not necessary to have trigger points/rate of
events?

... that those things will be discovered by the app in a
consistent/interoperable way

... will it not be a burden to discover trigger point/rate of events?

... is it good enough to have min/max

... and the other stuff will be figured out over time

dtran: that's the problem with dougt's proposal

... I work with sensors every day

... and you don't get information about trigger points

bryan: I like the simplicity of the current proposal

... my preference is

... ultimately, whatever makes it easiest for implementers

... we need to take into account that Intel is an implementer

<fjh> my point is that to progress a spec we need interop on optional
features, so having more in the spec makes it harder to progress

<Zakim> dsr, you wanted to ask about differences between dougt's and dtran's
API

dtran: I'd suggest you bring it up on the ML

... there's a thread on the HTML5/WhatWG ML

... I don't know how we can bring it back

fjh: I think bryan said he'd send an email about this

<dsr> dougt's proximity example: [http://dougturner.wordpress.com/2012/03/22
/device-proximity-sensor/][25] and dtran's [http://dvcs.w3.org/hg/dap/raw-
file/tip/sensor-api/Overview.html][26], AnssI's [http://dvcs.w3.org/hg/dap
/raw-file/tip/proximity/Overview.html][27]

dsr: there were some differences

... in dougt's proposal, he used window.eventlistener callback

... dtran's is different

... and AnssiK's is similar to dougt's

AnssiK: I looked at dougt's implementation and spec'd it out

... I don't have a position at this point

... I think it's easier to make progress if I write down what dougt
implemented

... and then make progress concurrently wit implementations

<fjh> makes sense to me

AnssiK: I don't know about dtran's proposal

dtran: previously the sensor spec

... allowed you to set threshold/rate of the sensor

... to report back to you

... I also updated my spec to be like dougt's

<dsr> Dave: Dzung's spec of May 8th uses different design from Doug and Anssi,
which do we want to take further?

dtran: I see AnssiK also did a separate spec

... we can have a discussion with dougt

... and update it to have features that I had

... I think that would be the approach

... I have some ideas how to do that

dsr: another question

... the whatwg list

... noted that if you don't have a sensor, or do have a sensor

... you shouldn't be able to detect if a sensor is present

dtran: that's sensor discovery

... the WG decided not to have Sensor Discovery for privacy/fingerprint
reasons

... that's why it was ripped out from the old spec

... we had that discussion many months ago

AnssiK: I took a similar design to the Battery status

... if the implementation can't report something

... I report a default value

... I looked at dougt's code

... and it assumed that it was always available

... that was something I added on top of dougt's spec to make it more complete

... it's something we need to flesh out in the group

... assuming this proposal is taken

... I don't have a hidden agenda here

... I just want to make the web kick ass on devices

... I'm happy to work with others, dougt, and dtran, etc.

<Zakim> nwidell, you wanted to ask about sensor discovery with web intents

AnssiK: I just want to move forward and get the work done

nwidell: we discussed discovery a long time ago

... some wanted JS and some wanted WebIntents

... I really liked dougt's proposal which is very simple

... is there a nice way to tie together WebIntents with this DOM Event based
sensor events?

... I haven't really figured that out

... can what is returned from WebIntents show up as a DOM Event in the caller?

dsr: that's valuable feedback to the WebIntent ML

... if you have remote-sensors, we'd like to be able to unify them

<fjh> interesting how webintents is considering sso/login as well

Josh_Soref: could have wrapper to generate DOM event, currently WebIntents
does not do on its own

### Gallery

<Jungkee> [The Gallery API][28]

<fjh> [Gallery API draft review request][29]

Jungkee: I had feedback from richt, bryan, and dougt

... the idea is to use WebIntents to locate galleries

... and access video/audio + metadata

... using intents callback

fjh: I think there was some concern about Size on the list

Jungkee: yes, I am now writing sample code

... I can probably share the demo code somewhere

... was discussed in an email thread

... I'd like to hear more from members here

... I can now update with more

... for which way of data delivery

... service providers can also

... interact

fjh: will you send out an email about this with a summary

Jungkee: for sure

fjh: thank you very much

### SLAPI

fjh: I don't think we need to talk about this

### Feature Permissions

<fjh> [Updated draft][30]

<fjh> [Move to Notification WG][31]

fjh: I don't think anything needs to be done

... lgombos, maybe you can follow up with the Notification WG

### Proximity

AnssiK: dtran agreed to be an editor for Proximity

... thanks dtran

### AOB

fjh: anything else to discuss?

dsr: AC meeting next week

... Phillipp Hoschka is leading a talk about

... Towards a Web Platform - that provides all that is needed for Mobile Apps,
and I will be covering the part that deals with system/browser safe APIs
including NFC and Bluetooth. I am more generally inviting anyone on DAP to
pass on any questions/concerns for the AC meeting.

bryan: one other thing

... in webapps f2f, there was a good

... discussion on test methodology

... test assertion

... there was a consensus on taking a tooling approach

... over a metadata approach

... definitely with these two specs that have reached CR

... want to help the test suite

fjh: there's a Media Capture call today

<Zakim> Josh_Soref, you wanted to comment on webapps minutes

Josh_Soref: I'll try to get webapps f2f minutes today

... and html-wg tomorrow

... with minutes from today's calls (DAP + MC) later

fjh: thanks everyone

... thanks Josh_Soref for scribing

[ Adjourned ]

trackbot, end meeting

## Summary of Action Items

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][32] version 1.135 ([CVS
log][33])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0052.html

   [4]: http://www.w3.org/2012/05/09-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

   [16]: http://www.w3.org/TR/2012/CR-battery-status-20120508/

   [17]: http://www.w3.org/TR/2012/CR-vibration-20120508/

   [18]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0046.html

   [19]: http://lists.w3.org/Archives/Public/public-device-
apis/2012Apr/0053.html

   [20]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0000.html

   [21]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0040.html

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2012Apr/att-0048/minutes-2012-04-25.html

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0041.html

   [24]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0053.html

   [25]: http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/

   [26]: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html

   [27]: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

   [28]: https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html

   [29]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0014.html

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0003.html

   [31]: http://lists.w3.org/Archives/Public/public-device-
apis/2012May/0024.html

   [32]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [33]: http://dev.w3.org/cvsweb/2002/scribe/