# Device APIs Working Group Teleconference

## 10 Oct 2013

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Josh_Soref, Lisa_DeLuca, Giri_Mandyam, Cathy_Chan,
Anssi_Kostiainen, JeanClaude_Dufourd, Dominique_Hazael-Massieux,
Tatsuya_Igarashi

Regrets


Chair

    Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Welcome, agenda review, scribe selection, announcements][6]

    2. [Minutes approval][7]

    3. [Proximity and Light][8]

    4. [Vibration][9]

    5. [Note publication][10]

    6. [Network Service Discovery][11]

    7. [Adjourn][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 10 October 2013

### Welcome, agenda review, scribe selection, announcements

<scribe> scribe: Josh_Soref

### Minutes approval

<fjh> Approve minutes from 3 October 2013

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/att-0024/minutes-2013-10-03.html][14]

**RESOLUTION: Minutes from 3 October 2013 are approved**

### Proximity and Light

anssik: i don't recall any discussion beyond naming -- which was handled last
week

### Vibration

<fjh> ISSUE-155?

<trackbot> ISSUE-155 -- Enable Feature Detection -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/155][15]

<fjh> ISSUE-150?

<trackbot> ISSUE-150 -- Should vibration be additive when multiple instances,
e.g. iframes -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/150][16]

Josh_Soref: vibrating is binary today... isn't it

... it is either vibrating ... or it isn't

<fjh> yes

Josh_Soref: so two different patterns as a bitwise OR

... would just result in the user not quite understanding the why for the
cumulative

... but it would be rather harmless, especially any timing shifts

fjh: i guess w/ audio and ads

... with two ads making music at the same time

... that's annoying

Josh_Soref: Google is trying to notify users as to which tab/thing is making
noise

anssik: Step 7 has an option for implementations to not vibrate

... if the implementation doesn't support additive vibration

... then it could cancel if there was a vibration active elsewhere

Josh_Soref: is it "if an implementation can't support?"

anssik: it's "an implementation MAY choose not to"

Josh_Soref: ok

fjh: as Josh_Soref noted if there's two different time coordinations

... then there would be some overlap

... but if the vibration only has one strength

... then i don't think it makes a difference

anssik: yeah, we don't have strength control

Josh_Soref: i'm fine with it

<anssik> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0003.html][17]

fjh: let's put a resolution that we'll adopt this change

<fjh> proposed RESOLUTION: Adopt proposal associated with ACTION-652:
[http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html][17]

**RESOLUTION: Adopt proposal associated with ACTION-652:
[http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0003.html][17]**

<fjh> **ACTION:** anssik to update Vibration draft per ACTION-652 [recorded in
[http://www.w3.org/2013/10/10-dap-minutes.html#action01][18]]

<trackbot> Created ACTION-665 - Update vibration draft per action-652 [on
Anssi Kostiainen - due 2013-10-17].

gmandyam: i'm not checking with the snapdragon people about whether the driver
supports additive

... but should we be doing this?

... if our chipset doesn't do this then it isn't supported in mobile devices

fjh: we're in CR

... it's a call for implementations

... if you're implementing the spec, then it's good to see what you can
implement

Josh_Soref: if i'm an implementation

... and the driver is vibrating

... and i call stop() and then call vibrate(pattern)

... where i've merged the two patterns i had

... would it work such that the user wouldn't notice that i've interrupted and
restarted with a new pattern

fjh: there might be moments where it's not vibrating

Josh_Soref: but if it's fast enough, then the user might not notice

fjh: gmandyam, it's good to check to see if it works

gmandyam: anssik, i assume Intel is checking too?

anssik: sure

... we're getting feedback from the Google guys working on the Chrome
implementation

... they seem to be +1'ing the design

<fjh> **ACTION:** gmandyam to check with internal implementers whether
vibration API is consistent with chip capabilities [recorded in
[http://www.w3.org/2013/10/10-dap-minutes.html#action02][19]]

<trackbot> Created ACTION-666 - Check with internal implementers whether
vibration api is consistent with chip capabilities [on Giridhar Mandyam - due
2013-10-17].

fjh: gmandyam raised a point that there's the browser+software

... but there's also the hardware and what it can do

... but there's Josh_Soref 's point about whether it's not noticable

anssik: yeah

... if we move to Advanced features like Strength

... there might be problems that

fjh: I think what Josh_Soref is suggesting would be good enough in the real
world

anssik: yeah, i think the main thing is that the latency between invoking the
method and when it happens be as close to 0

... this is a Quality of Implementation

... the less latency, the better the implementation

<fjh> ISSUE-149?

<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no
vibration at all -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/149][20]

fjh: i think Josh_Soref raised the concern that what if the numbers are
inconsistent wrt their values

... you might miss it if you truncate early

... not sure what you can do, if you can't handle it, you can't handle it

... what can you do instead?

Josh_Soref: not doing it at all/returning an error?

fjh: that might make more sense

... if the question is... best effort / do/fail

<fjh> from last week's minutes from josh [1, 2, 3, 4, 1000, 2, 1000]

fjh: if the limit is 4

... then you get 1,2,3,4

... if you just truncate, you miss the main thrust of the vibration

<anssik> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0012.html][21]

fjh: i don't think you can determine if it's ok/not-ok to truncate

... anssik 's proposal is to truncate..

<dom> (truncating seems fine to me fwiw)

Josh_Soref: i think a consumer would rather call it repeatedly to make it work

... instead of having it truncated

fjh: i don't know why an implementation couldn't do that too

Josh_Soref: i think we should set a minimum number of slots and time

... that the UA might be expected to split it into multiple driver calls

fjh: i think maximum supported by UAs will be rather specific and change over
time

... maybe there should be a should for minimums

<fjh> Minimum. pattern list supported SHOULD be 6

dom: we might be overengineering

... we aren't trying to design a mission critical api

... it would be nice to be able to make a strong promise

... but a best effort approach is really just as good

fjh: the question is whether a best effort, which i tend to prefer

... in the internet, if you lose packets in best effort, you don't signal

... the recipient has to notice

dom: your internet analogy is good

... you use reliable, or unreliable

... if you use reliable, you pay a cost, but know

Josh_Soref: HTTP is reliable (TCP)

fjh: if i write this pattern, and it doesn't work on a device, the only way i
know is if i test on the devices

... and if i don't test, i'm not concerned

dom: there might be a vibration v20 with callbacks

... if the UA determines it can't run a sequence of 6 on a given hardware

... "it" could implement a fallback

... if you want 50ms separated set of 6 vibrations

... and the default implementation on the platform only goes to 5

... the UA could do the right thing and trigger an additional 6th vibration

... that's transparent from the web application perspective

... i think UAs will do the right thing

... picking a minimum iterations seems to be too much effort

<LisaDeLuca_IBM> off topic: what is the default delay/time between vibrations?
I'm assuming that can't be set by the developer

fjh: shouldn't we have a minimum of at least 2?

dom: unless UAs would intentionally cripple their implementations

... either UAs have a good reason to restrict to a very low value for example
when the battery is low

... then there's

Josh_Soref: LisaDeLuca_IBM the pattern lets you set a delay between
"vibrating" and "vibrating again"

... how the device "vibrates" is up to the device/ua

fjh: dom, you're saying it's a QoI

... but Josh_Soref 's point of being able to rely on the spec

... both are true

... but truncation would need to happen if you do 6 million things

... we should incorporate what anssik has

... and if gmandyam gives feedback

gmandyam: i have a tendency to think that if you're looking at it from a
browser perspective

<LisaDeLuca_IBM> @Josh_Soref, thanks, which number is the delay in here:
navigator.vibrate([50, 100, 150, 100, 150]); x = vibrate x+1 = delay before
next vibrate?

gmandyam: they're stuck w/ best effort

... if the hardware can't do something, they won't be able to provide it back
up to js

... looking at android's vibrator api, they don't distinguish the type of
error

... whether the platform doesn't support a type of pattern

... a lot of browsers will implement using the android vibrator api

Josh_Soref: LisaDeLuca_IBM, i believe it vibrates for 50 time, doesn't vibrate
for 100 time, vibrates for 150, doesn't vibrate for 100 time...

... i can't imagine it would be hard for an implementer to guarantee 6 and
some time window

... if you can't, i'd expect it'd be better if you didn't implement

dom: i'm not sure how it's going to be used

fjh: i think we should incorporate anssik 's proposal

... and put in a note about how it could be broken into pieces by the
UA/Application

... and that we might revisit having a minimum pattern

Josh_Soref: that works for me

<fjh> proposed RESOLUTION: Adopt proposal as in
[http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0012.html][21], adding Note that implementation may break into
multiple pieces if list too long , potential concern if best effort does not
meet application expectations

fjh: ... and it's appropriate to truncate in cases of DoS

anssik: this is a note geared to developers

fjh: but breaking to multiple pieces could be done by UAs

anssik: i thought implementers could figure that out themselves

fjh: they could, but we might as well mention it

... it gives more information to the readers

... i don't think it's harmful to include it in text

... are we ok w/ this proposal?

anssik: could someone propose spec text

... i'd appreciate that

<dom> (I personally feel it's superfluous, but not to the point of objecting
to it)

**RESOLUTION: Adopt proposal as in [http://lists.w3.org/Archives/Public
/public-device-apis/2013Oct/0012.html][21], adding Note that implementation
may break into multiple pieces if list too long , potential concern if best
effort does not meet application expectations**

<fjh> **ACTION:** fjh to draft note corresponding to resolution [recorded in
[http://www.w3.org/2013/10/10-dap-minutes.html#action03][22]]

<trackbot> Created ACTION-667 - Draft note corresponding to resolution [on
Frederick Hirsch - due 2013-10-17].

<fjh> ISSUE-155?

<trackbot> ISSUE-155 -- Enable Feature Detection -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/155][15]

fjh: the UC is to offer a visual alternative

anssik: one concern i have is that this feature has been shipping in Firefox
for at least a year

... if we move to this proposal, we'd break on firefox, right?

dom: if we were to adopt the exact proposal, i think it would

... since it moves vibration out of navigator

... could we move to that model in addition to the existing one?

... it seems like a v2 question

... i don't feel very strongly about it

... i guess it would be useful if there were stronger UCs

anssik: i could see this would be a generic pattern for future APIs

dom: one reason we didn't make it detectable was for fingerprinting

... i think we should respond to michael

... summarizing why not so far

... and that if we would, it would be in a broader framework

<fjh> **ACTION:** anssik to respond to Michael re ISSUE-155 , existing
implementations, v2 possibility [recorded in [http://www.w3.org/2013/10/10
-dap-minutes.html#action04][23]]

<trackbot> Created ACTION-668 - Respond to michael re issue-155 , existing
implementations, v2 possibility [on Anssi Kostiainen - due 2013-10-17].

anssik: i think they're trying to find a way to support it only on platforms
where it exists

dom: that's not unreasonable

<gmandyam> Have to leave. See you next week. - Giri

<fjh> +1, not unreasonable to enable alternative visible approach

dom: it's frustrating to invoke a method if it doesn't do anything

### Note publication

<fjh> CfC, publish W3C Notes for shelved and exploratory drafts

fjh: we have a requirements document that's an ED

anssik: if there's nothing in /TR/, then we don't want to publish

... i want to fix obsolete things on /TR/

fjh: so, if we published a draft before

... you're concerned they can find the WD

anssik: if you google, you'll find the /TR/, not the editor's draft

fjh: i don't want to point to ED

... let's publish as NOTE and be done

anssik: ok, it's a bit of a PITA

<LisaDeLuca_IBM> Dropping at the top of the hour for another call. Feel free
to assign an action to me to help with the battery tests. I will go through
@anssik's email and help with those tests.

fjh: it's a pain to do the link-checker

... anssik, you made a list in your email

dom: i can take a subset if that helps

... my schedule isn't great until the end of next week

... but assuming it isn't urgent

... i can take a few documents

fjh: there's no emergency, we've sat on this for years

anssik: fjh, you had a concern with the note we have in the document

<anssik> [http://www.w3.org/TR/webdatabase/][24]

fjh: if we publish as NOTE, we should adhere to PubRules and make the status
section meaningful

dom: we can follow WebSQL

... PubRules leaves freedom wrt Appearance

anssik: i think i stole the stylesheet from the WebSQL

... but i made it less scary than that

fjh: i think it's interesting when you look at contact/calendar

... not sure what they're doing in SysApps

... but i think some of it is still relevant

anssik: this is one of the things that causes confusion

... if there are two specs, what should an implementer do

fjh: did this happen inside intel?

anssik: both public and internal feedback

... i just wanted to get this done now

fjh: there are some publication moratoriums

... coming up

dom: my thinking is that we'd publish all notes on the same day

... and either not have an announce

... or have an announcement that "dap decides having not made progress ..."

... my preference is the former

... making it as a piece of news now, when we decided a while ago would be
confusing

<fjh> i would not want a news item on non-progress, nor news that could
confuse

anssik: i think w3c should adjust its new process

dom: i think we can specify we don't want news

fjh: it's less work to not have a news item

anssik: i know automotive is looking at temperature

... but their UCs are different (indoor, outdoor, ...)

... it's something different

fjh: wondering about IPR perspective

... but not moving things to REC, we don't get IPR obligations

... i'd assume there's so much prior-art

dom: patent policy on something not implemented has no value

... this documents aren't progressing because no one is implementing

... no big deal if you lose the protection

fjh: someone might wake up and if they implement

... they might implement

dom: if they wake up, they'd realize it sucks

... and fix it and get it to REC

fjh: ok

Josh_Soref: +1

<fjh> goal is to publish notes for docs previously published (in TR) not for
all

<fjh> this will simplify CfC

### Network Service Discovery

<fjh> Web & TV IG review in progress

<fjh> wiki [http://www.w3.org/2009/dap/wiki/NSD_Security][25]

<fjh> PING Review (deferred to follow additional updates)

<fjh> Rich has updated the draft for CORS

fjh: how should we use this call? jcdufourd ?

jcdufourd: no idea

fjh: i think we need to review what richt just released

... Cathy ?

Cathy: i need to read richt's update

... there might be some discussions that fell off the radar

... igarashi's proposal

<fjh> ISSUE-131?

<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/131][26]

fjh: there's so much going on

... we should get things down

jcdufourd: question about exposing URLs at all

... that would change significantly how things work

... only richt responded

<Zakim> Josh_Soref, you wanted to talk about CORS

jcdufourd: wonder if other people had a feeling

Josh_Soref: URLs allow CORS whitelisting to be meaningful

... and allows consumers to use WebSockets or similar

... but our security concerns aren't limited to any particular way to talk to
devices

... it's that devices are buggy

... changing how you talk to a device won't solve that

<fjh> proposal is blacklist for routers for example

fjh: i think blacklisting of routers helps

Josh_Soref: +1

... security concerns are rather unrelated to CORS/introduction of an
application to a device

jcdufourd: i was concerned about the necessity of CORS

... with CORS+WebSocket/XHR

... if we had a way not to

... need WebSocket/XHR

... do our own protocol

... it's more limited + easier to secure

... i thought that would help

... disappearance of URLs/fingerprinting

... but richt+Josh_Soref don't think that helps

... w/o CORS/WebSocket/XHR

fjh: simplicity is important here

... it's very complex in terms of mappings

... i think this requires more thought

... i'm going to re-read and think about it more

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** anssik to respond to Michael re ISSUE-155 , existing
implementations, v2 possibility [recorded in [http://www.w3.org/2013/10/10
-dap-minutes.html#action04][23]]

**[NEW]** **ACTION:** anssik to update Vibration draft per ACTION-652
[recorded in [http://www.w3.org/2013/10/10-dap-minutes.html#action01][18]]

**[NEW]** **ACTION:** fjh to draft note corresponding to resolution [recorded
in [http://www.w3.org/2013/10/10-dap-minutes.html#action03][22]]

**[NEW]** **ACTION:** gmandyam to check with internal implementers whether
vibration API is consistent with chip capabilities [recorded in
[http://www.w3.org/2013/10/10-dap-minutes.html#action02][19]]


[End of minutes]

* * *

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

$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/2013Oct/0088.html

   [4]: http://www.w3.org/2013/10/10-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

   [14]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/att-0024/minutes-2013-10-03.html

   [15]: http://www.w3.org/2009/dap/track/issues/155

   [16]: http://www.w3.org/2009/dap/track/issues/150

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0003.html

   [18]: http://www.w3.org/2013/10/10-dap-minutes.html#action01

   [19]: http://www.w3.org/2013/10/10-dap-minutes.html#action02

   [20]: http://www.w3.org/2009/dap/track/issues/149

   [21]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Oct/0012.html

   [22]: http://www.w3.org/2013/10/10-dap-minutes.html#action03

   [23]: http://www.w3.org/2013/10/10-dap-minutes.html#action04

   [24]: http://www.w3.org/TR/webdatabase/

   [25]: http://www.w3.org/2009/dap/wiki/NSD_Security

   [26]: http://www.w3.org/2009/dap/track/issues/131

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

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