13:47:05 RRSAgent has joined #dap 13:47:05 logging to http://www.w3.org/2013/10/10-dap-irc 13:47:07 RRSAgent, make logs world 13:47:07 Zakim has joined #dap 13:47:09 Zakim, this will be DAP 13:47:09 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 13 minutes 13:47:10 Meeting: Device APIs Working Group Teleconference 13:47:10 Date: 10 October 2013 13:47:13 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0088.html 13:47:27 fjh has changed the topic to: dap 3279 ; agenda http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0088.html 13:47:45 Chair: Frederick_Hirsch 13:47:48 Present+ Frederick_Hirsch 13:48:04 Topic: Welcome, agenda review, scribe selection, announcements 13:50:12 LisaDeLuca_IBM has joined #dap 13:57:33 igarashi has joined #dap 13:58:41 gmandyam has joined #dap 13:59:07 UW_DAP()10:00AM has now started 13:59:14 +gmandyam 13:59:42 Zakim, code? 13:59:42 the conference code is 3279 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Josh_Soref 13:59:59 +[IPcaller] 14:00:09 zakim, [IPcaller] is me 14:00:09 +fjh; got it 14:00:12 +Mark_Baker 14:00:15 zakim, who is here? 14:00:15 On the phone I see gmandyam, fjh, Mark_Baker 14:00:16 On IRC I see gmandyam, igarashi, LisaDeLuca_IBM, Zakim, RRSAgent, fjh, tobie, richt, dom, Josh_Soref, slightlyoff, anssik, mounir, trackbot 14:00:35 +??P12 14:00:42 Zakim, Mark_Baker is me 14:00:42 +Josh_Soref; got it 14:00:46 + +1.415.787.aaaa 14:00:47 Zakim, mute me 14:00:48 Josh_Soref should now be muted 14:00:52 richt has joined #dap 14:01:03 Zakim, aaaa is LisaDeLuca_IBM 14:01:03 +LisaDeLuca_IBM; got it 14:01:18 zakim, aaaa is LisaDeLuca_IBM 14:01:18 sorry, fjh, I do not recognize a party named 'aaaa' 14:01:20 +??P12 is igarashi 14:01:29 scribe: Josh_Soref 14:01:48 Zakim, unmute me 14:01:48 Josh_Soref should no longer be muted 14:02:29 +??P10 14:02:32 zakim, ??P10 is me 14:02:32 +anssik; got it 14:02:39 Present+ Anssi_Kostiainen 14:03:01 +??P2 14:03:07 zakim, ??P12 is me 14:03:07 +igarashi; got it 14:03:13 Sorry to hear you will be leaving DAP, Josh - you were a lot of help to me during the past year. 14:03:35 +??P1 14:03:41 s/Sorry to hear you will be leaving DAP, Josh - you were a lot of help to me during the past year.// 14:03:47 Zakim, ??P1 is me 14:03:47 +dom; got it 14:04:10 jcdufourd has joined #dap 14:04:47 Present+ JeanClaude_Dufourd 14:04:48 -??P2 14:05:12 +??P2 14:05:28 RRSAgent, draft minutes 14:05:28 I have made the request to generate http://www.w3.org/2013/10/10-dap-minutes.html Josh_Soref 14:05:39 RRSAgent, draft minutes 14:05:39 I have made the request to generate http://www.w3.org/2013/10/10-dap-minutes.html Josh_Soref 14:05:53 s/+??P12 is igarashi// 14:06:00 RRSAgent, draft minutes 14:06:00 I have made the request to generate http://www.w3.org/2013/10/10-dap-minutes.html Josh_Soref 14:06:22 Zakim, who's on the call? 14:06:22 On the phone I see gmandyam, fjh, Josh_Soref, igarashi, LisaDeLuca_IBM, anssik, dom, JeanClaude_Dufourd 14:06:24 RRSAgent, draft minutes 14:06:24 I have made the request to generate http://www.w3.org/2013/10/10-dap-minutes.html Josh_Soref 14:07:02 zakim, who is here? 14:07:02 On the phone I see gmandyam, fjh, Josh_Soref, igarashi, LisaDeLuca_IBM, anssik, dom, JeanClaude_Dufourd 14:07:04 On IRC I see jcdufourd, richt, gmandyam, igarashi, LisaDeLuca_IBM, Zakim, RRSAgent, fjh, tobie, dom, Josh_Soref, slightlyoff, anssik, mounir, trackbot 14:08:08 topic: Minutes approval 14:08:11 Approve minutes from 3 October 2013 14:08:12 http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/att-0024/minutes-2013-10-03.html 14:08:21 RESOLUTION: Minutes from 3 October 2013 are approved 14:08:30 topic: Proximity and Light 14:08:50 anssik: i don't recall any discussion beyond naming -- which was handled last week 14:08:56 topic: Vibration 14:09:14 ISSUE-155? 14:09:14 ISSUE-155 -- Enable Feature Detection -- open 14:09:14 http://www.w3.org/2009/dap/track/issues/155 14:09:37 ISSUE-150? 14:09:37 ISSUE-150 -- Should vibration be additive when multiple instances, e.g. iframes -- open 14:09:37 http://www.w3.org/2009/dap/track/issues/150 14:10:45 Josh_Soref: vibrating is binary today... isn't it 14:10:51 ... it is either vibrating ... or it isn't 14:11:02 yes 14:11:03 ... so two different patterns as a bitwise OR 14:11:18 ... would just result in the user not quite understanding the why for the cumulative 14:11:28 ... but it would be rather harmless, especially any timing shifts 14:12:00 fjh: i guess w/ audio and ads 14:12:05 ... with two ads making music at the same time 14:12:08 ... that's annoying 14:12:20 Josh_Soref: Google is trying to notify users as to which tab/thing is making noise 14:12:28 anssik: Step 7 has an option for implementations to not vibrate 14:12:38 ... if the implementation doesn't support additive vibration 14:12:49 ... then it could cancel if there was a vibration active elsewhere 14:13:28 Josh_Soref: is it "if an implementation can't support?" 14:13:38 anssik: it's "an implementation MAY choose not to" 14:13:39 Josh_Soref: ok 14:13:50 fjh: as Josh_Soref noted if there's two different time coordinations 14:13:55 ... then there would be some overlap 14:14:04 ... but if the vibration only has one strength 14:14:11 ... then i don't think it makes a difference 14:14:22 anssik: yeah, we don't have strength control 14:14:26 Josh_Soref: i'm fine with it 14:14:37 http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html 14:14:54 fjh: let's put a resolution that we'll adopt this change 14:15:22 q+ 14:15:51 proposed RESOLUTION: Adopt proposal associated with ACTION-652: http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html 14:16:22 RESOLUTION: Adopt proposal associated with ACTION-652: http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html 14:16:53 action: anssik to update Vibration draft per ACTION-652 14:16:53 Created ACTION-665 - Update vibration draft per action-652 [on Anssi Kostiainen - due 2013-10-17]. 14:16:57 q? 14:17:01 ack gmandyam 14:17:31 gmandyam: i'm not checking with the snapdragon people about whether the driver supports additive 14:17:36 ... but should we be doing this? 14:17:40 q+ Josh_Soref 14:17:54 ack josh_soref 14:18:04 ... if our chipset doesn't do this then it isn't supported in mobile devices 14:18:11 fjh: we're in CR 14:18:14 ... it's a call for implementations 14:18:27 ... if you're implementing the spec, then it's good to see what you can implement 14:19:02 Cathy has joined #dap 14:19:06 Josh_Soref: if i'm an implementation 14:19:12 ... and the driver is vibrating 14:19:22 ... and i call stop() and then call vibrate(pattern) 14:19:30 ... where i've merged the two patterns i had 14:19:46 ... would it work such that the user wouldn't notice that i've interrupted and restarted with a new pattern 14:20:07 fjh: there might be moments where it's not vibrating 14:20:08 +Cathy 14:20:14 Josh_Soref: but if it's fast enough, then the user might not notice 14:20:27 fjh: gmandyam, it's good to check to see if it works 14:20:35 gmandyam: anssik, i assume Intel is checking too? 14:20:36 anssik: sure 14:20:48 ... we're getting feedback from the Google guys working on the Chrome implementation 14:20:52 ... they seem to be +1'ing the design 14:21:01 action: gmandyam to check with internal implementers whether vibration API is consistent with chip capabilities 14:21:01 Created ACTION-666 - Check with internal implementers whether vibration api is consistent with chip capabilities [on Giridhar Mandyam - due 2013-10-17]. 14:21:50 fjh: gmandyam raised a point that there's the browser+software 14:21:56 ... but there's also the hardware and what it can do 14:22:08 ... but there's Josh_Soref 's point about whether it's not noticable 14:22:10 anssik: yeah 14:22:30 ... if we move to Advanced features like Strength 14:22:36 ... there might be problems that 14:22:49 fjh: I think what Josh_Soref is suggesting would be good enough in the real world 14:23:09 anssik: yeah, i think the main thing is that the latency between invoking the method and when it happens be as close to 0 14:23:24 anssik: this is a QoI 14:23:32 ... the less latency, the better the implementation 14:24:04 ISSUE-149? 14:24:05 ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open 14:24:05 http://www.w3.org/2009/dap/track/issues/149 14:24:28 fjh: i think Josh_Soref raised the concern that what if the numbers are inconsistent wrt their values 14:24:36 ... you might miss it if you truncate early 14:24:47 ... not sure what you can do, if you can't handle it, you can't handle it 14:24:58 ... what can you do instead? 14:25:05 Josh_Soref: not doing it at all/returning an error? 14:25:10 fjh: that might make more sense 14:25:23 ... if the question is... best effort / do/fail 14:26:14 from last week's minutes from josh [1, 2, 3, 4, 1000, 2, 1000] 14:26:48 fjh: if the limit is 4 14:26:59 ... then you get 1,2,3,4 14:27:13 ... if you just truncate, you miss the main thrust of the vibration 14:27:13 http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html 14:28:10 fjh: i don't think you can determine if it's ok/not-ok to truncate 14:28:20 ... anssik 's proposal is to truncate.. 14:28:58 (truncating seems fine to me fwiw) 14:29:32 Josh_Soref: i think a consumer would rather call it repeatedly to make it work 14:29:37 ... instead of having it truncated 14:29:47 fjh: i don't know why an implementation couldn't do that too 14:30:16 Josh_Soref: i think we should set a minimum number of slots and time 14:30:36 ... that the UA might be expected to split it into multiple driver calls 14:31:35 fjh: i think maximum supported by UAs will be rather specific and change over time 14:32:05 fjh: maybe there should be a should for minimums 14:33:16 Miminum pattern list supported SHOULD be 6 14:34:24 s/Miminum/Minimum. 14:34:41 dom: we might be overengineering 14:34:53 ... we aren't trying to design a mission critical api 14:35:03 ... it would be nice to be able to make a strong promise 14:35:11 ... but a best effort approach is really just as good 14:35:22 fjh: the question is whether a best effort, which i tend to prefer 14:35:32 ... in the internet, if you lose packets in best effort, you don't signal 14:35:39 ... the recipient has to notice 14:35:48 dom: your internet analogy is good 14:35:53 ... you use reliable, or unreliable 14:36:00 ... if you use reliable, you pay a cost, but know 14:36:06 Josh_Soref: HTTP is reliable (TCP) 14:36:37 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 14:36:45 ... and if i don't test, i'm not concerned 14:36:53 dom: there might be a vibration v20 with callbacks 14:38:17 dom: if the UA determines it can't run a sequence of 6 on a given hardware 14:38:27 ... "it" could implement a fallback 14:38:35 ... if you want 50ms separated set of 6 vibrations 14:38:43 ... and the default implementation on the platform only goes to 5 14:38:55 ... the UA could do the right thing and trigger an additional 6th vibration 14:39:02 ... that's transparent from the web application perspective 14:39:51 dom: i think UAs will do the right thing 14:40:04 ... picking a minimum iterations seems to be too much effort 14:40:08 off topic: what is the default delay/time between vibrations? I'm assuming that can't be set by the developer 14:40:14 fjh: shouldn't we have a minimum of at least 2? 14:40:26 dom: unless UAs would intentionally cripple their implementations 14:40:41 ... either UAs have a good reason to restrict to a very low value (no battery?) 14:40:48 ... then there's 14:41:06 Josh_Soref: LisaDeLuca_IBM the pattern lets you set a delay between "vibrating" and "vibrating again" 14:41:12 s/(no battery?)/for example when the battery is low 14:41:19 ... how the device "vibrates" is up to the device/ua 14:41:26 lgombos has joined #dap 14:41:31 fjh: dom, you're saying it's a QoI 14:41:40 ... but Josh_Soref 's point of being able to rely on the spec 14:41:43 ... both are true 14:41:54 ... but truncation would need to happen if you do 6 million things 14:41:57 q+ 14:42:00 ... we should incorporate what anssik has 14:42:05 ... and if gmandyam gives feedback 14:42:18 ack gmandyam 14:42:19 ack gmandyam 14:42:23 q? 14:42:29 gmandyam: i have a tendency to think that if you're looking at it from a browser perspective 14:42:32 @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? 14:42:36 ... they're stuck w/ best effort 14:42:58 s/Qoi/quality of implementation/ 14:43:07 ... if the hardware can't do something, they won't be able to provide it back up to js 14:43:09 rrsagent, generate minutes 14:43:09 I have made the request to generate http://www.w3.org/2013/10/10-dap-minutes.html fjh 14:43:20 ... looking at android's vibrator api, they don't distinguish the type of error 14:43:28 ... whether the platform doesn't support a type of pattern 14:43:42 ... a lot of browsers will implement using the android vibrator api 14:44:03 q- 14:44:36 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... 14:45:39 s/QoI/quality of implementation/ 14:45:57 Josh_Soref: i can't imagine it would be hard for an implementer to guarantee 6 and some time window 14:46:00 -Cathy 14:46:10 ... if you can't, i'd expect it'd be better if you didn't implement 14:46:19 dom: i'm not sure how it's going to be used 14:46:27 fjh: i think we should incorporate anssik 's proposal 14:46:41 ... and put in a note about how it could be broken into pieces by the UA/Application 14:46:50 ... and that we might revisit having a minimum pattern 14:46:59 Josh_Soref: that works for me 14:47:48 +Cathy 14:48:19 proposed RESOLUTION: Adopt proposal as in http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html, adding Note that implementation may break into multiple pieces if list too long , potential concern if best effort does not meet application expectations 14:48:56 fjh: ... and it's appropriate to truncate in cases of DoS 14:49:04 anssik: this is a note geared to developers 14:49:13 fjh: but breaking to multiple pieces could be done by UAs 14:49:26 anssik: i thought implementers could figure that out themselves 14:49:32 fjh: they could, but we might as well mention it 14:49:39 ... it gives more information to the readers 14:49:49 ... i don't think it's harmful to include it in text 14:50:07 ... are we ok w/ this proposal? 14:50:25 anssik: could someone propose spec text 14:50:30 ... i'd appreciate that 14:50:34 (I personally feel it's superfluous, but not to the point of objecting to it) 14:50:37 RESOLUTION: Adopt proposal as in http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html, adding Note that implementation may break into multiple pieces if list too long , potential concern if best effort does not meet application expectations 14:50:52 action: fjh to draft note corresponding to resolution 14:50:53 Created ACTION-667 - Draft note corresponding to resolution [on Frederick Hirsch - due 2013-10-17]. 14:51:18 ISSUE-155? 14:51:18 ISSUE-155 -- Enable Feature Detection -- open 14:51:18 http://www.w3.org/2009/dap/track/issues/155 14:51:57 fjh: the UC is to offer a visual alternative 14:52:09 anssik: one concern i have is that this feature has been shipping in Firefox for at least a year 14:52:43 ... if we move to this proposal, we'd break on firefox, right? 14:52:55 dom: if we were to adopt the exact proposal, i think it would 14:53:01 ... since it moves vibration out of navigator 14:53:13 ... could we move to that model in addition to the existing one? 14:53:17 ... it seems like a v2 question 14:53:23 ... i don't feel very strongly about it 14:53:32 ... i guess it would be useful if there were stronger UCs 14:53:43 ... i could see this would be a generic pattern for future APIs 14:53:50 s/.../anssik:/ 14:54:16 dom: one reason we didn't make it detectable was for fingerprinting 14:54:24 ... i think we should respond to michael 14:54:28 ... summarizing why not so far 14:54:38 ... and that if we would, it would be in a broader framework 14:55:16 action: anssik to respond to Michael re ISSUE-155 , existing implementations, v2 possibility 14:55:16 Created ACTION-668 - Respond to michael re issue-155 , existing implementations, v2 possibility [on Anssi Kostiainen - due 2013-10-17]. 14:55:18 anssik: i think they're trying to find a way to support it only on platforms where it exists 14:55:29 dom: that's not unreasonable 14:55:39 Have to leave. See you next week. - Giri 14:55:42 +1, not unreasonable to enable alternative visible approach 14:55:42 ... it's frustrating to invoke a method if it does'nt do anything 14:55:45 -gmandyam 14:55:46 s/s'n/sn'/ 14:56:43 topic: Note publication 14:57:32 CfC, publish W3C Notes for shelved and exploratory drafts 14:57:55 fjh: we have a requirements document that's an ED 14:58:02 anssik: if there's nothing in /TR/, then we don't want to publish 14:58:08 ... i want to fix obsolete things on /TR/ 14:58:16 fjh: so, if we published a draft before 14:58:22 ... you're concerned they can find the WD 14:58:45 anssik: if you google, you'll find the /TR/, not the editor's draft 14:58:58 fjh: i don't want to point to ED 14:59:03 ... let's publish as NOTE and be done 14:59:10 anssik: ok, it's a bit of a PITA 14:59:19 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. 14:59:55 fjh: it's a pain to do the link-checker 15:00:11 ... anssik, you made a list in your email 15:00:19 dom: i can take a subset if that helps 15:00:26 ... my schedule isn't great until the end of next week 15:00:30 ... but assuming it isn't urgent 15:00:35 ... i can take a few documents 15:00:43 fjh: there's no emergency, we've sat on this for years 15:00:58 anssik: fjh, you had a concern with the note we have in the document 15:01:16 http://www.w3.org/TR/webdatabase/ 15:01:16 fjh: if we publish as NOTE, we should adhere to PubRules and make the status section meaningful 15:01:58 dom: we can follow WebSQL 15:02:05 ... PubRules leaves freedom wrt Appearance 15:02:18 anssik: i think i stole the stylesheet from the WebSQL 15:02:28 ... but i made it less scary than that 15:02:37 fjh: i think it's interesting when you look at contact/calendar 15:02:44 ... not sure what they're doing in SysApps 15:02:50 ... but i think some of it is still relevant 15:02:59 anssik: this is one of the things that causes confusion 15:03:08 ... if there are two specs, what should an implementer do 15:03:15 fjh: did this happen inside intel? 15:03:20 anssik: both public and internal feedback 15:03:25 ... i just wanted to get this done now 15:03:45 fjh: there are some publication moratoriums 15:03:45 coming up 15:03:52 s/ coming/... coming/ 15:04:13 dom: my thinking is that we'd publish all notes on the same day 15:04:20 ... and either not have an announce 15:04:37 ... or have an announcement that "dap decides having not made progress ..." 15:04:41 ... my preference is the former 15:04:51 ... making it as a piece of news now, when we decided a while ago would be confusing 15:04:59 i would not want a news item on non-progress, nor news that could confuse 15:04:59 anssik: i think w3c should adjust its new process 15:05:10 dom: i think we can specify we don't want news 15:05:16 fjh: it's less work to not have a news item 15:06:18 anssik: i know automotive is looking at temperature 15:06:26 ... but their UCs are different (indoor, outdoor, ...) 15:06:30 ... it's something different 15:06:38 fjh: wondering about IPR perspective 15:06:45 ... but not moving things to REC, we don't get IPR obligations 15:06:57 ... i'd assume there's so much prior-art 15:07:12 dom: patent policy on something not implemented has no value 15:07:25 ... this documents aren't progressing because no one is implementing 15:07:33 ... no big deal if you lose the protection 15:07:41 fjh: someone might wake up and if they implement 15:07:45 ... they might implement 15:07:51 dom: if they wake up, they'd realize it sucks 15:07:55 ... and fix it and get it to rec 15:07:58 s/rec/REC/ 15:08:00 fjh: ok 15:08:01 Josh_Soref: +1 15:08:13 goal is to publish notes for docs previously published (in TR) not for all 15:08:25 this will simplify CfC 15:08:35 zakim, who is here? 15:08:35 On the phone I see fjh, Josh_Soref, igarashi, LisaDeLuca_IBM, anssik, dom, JeanClaude_Dufourd, Cathy 15:08:37 On IRC I see Cathy, jcdufourd, igarashi, LisaDeLuca_IBM, Zakim, RRSAgent, fjh, dom, Josh_Soref, slightlyoff, anssik, mounir, trackbot 15:08:45 topic: Network Service Discovery 15:08:55 Web & TV IG review in progress 15:09:04 wiki http://www.w3.org/2009/dap/wiki/NSD_Security 15:09:16 PING Review (deferred to follow additional updates) 15:09:37 Rich has updated the draft for CORS 15:10:12 fjh: how should we use this call? jcdufourd ? 15:10:15 jcdufourd: no idea 15:10:16 tobie has joined #dap 15:10:23 fjh: i think we need to review what richt just released 15:10:26 fjh: Cathy ? 15:10:32 Cathy: i need to read richt's update 15:10:47 ... there might be some discussions that fell off the radar 15:11:04 ... igarashi's proposal 15:11:30 ISSUE-131? 15:11:30 ISSUE-131 -- Support UPnP device discovery by Device Type? -- open 15:11:30 http://www.w3.org/2009/dap/track/issues/131 15:12:32 lgombos has joined #dap 15:12:46 fjh: there's so much going on 15:12:51 ... we should get things down 15:13:24 jcdufourd: question about exposing URLs at all 15:13:32 ... that would change significantly how things work 15:13:36 ... only richt responded 15:13:37 q? 15:13:41 q+ Josh_Soref to talk about CORS 15:13:46 q+ 15:13:55 ack Josh_soref 15:13:56 Josh_Soref, you wanted to talk about CORS 15:13:56 ... wonder if other people had a feeling 15:14:40 -dom 15:15:09 Josh_Soref: URLs allow CORS whitelisting to be meaningful 15:15:17 ... and allows consumers to use WebSockets or similar 15:15:33 ... but our security concerns aren't limited to any particular way to talk to devices 15:15:37 ... it's that devices are buggy 15:15:44 ... changing how you talk to a device won't solve that 15:15:49 proposal is blacklist for routers for example 15:15:52 fjh: i think blacklisting of routers helps 15:15:54 Josh_Soref: +1 15:16:18 Josh_Soref: security concerns are rather unrelated to CORS/introduction of an application to a device 15:17:30 jcdufourd: i was concerned about the necessity of CORS 15:17:36 ... with CORS+WebSocket/XHR 15:17:40 ... if we had a way not to 15:17:46 ... need WebSocket/XHR 15:17:51 ... do our own protocol 15:17:56 ... it's more limited + easier to secure 15:18:02 ... i thought that would help 15:18:08 ... disappearance of URLs/fingerprinting 15:18:14 ... but richt+Josh_Soref don't think that helps 15:18:22 ... w/o CORS/WebSocket/XHR 15:18:29 fjh: simplicity is important here 15:18:41 ... it's very complex in terms of mappings 15:18:46 ... i think this requires more thought 15:19:21