See also: IRC log
<trackbot> Date: 10 October 2013
<scribe> scribe: Josh_Soref
<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
RESOLUTION: Minutes from 3 October 2013 are approved
anssik: i don't recall any discussion beyond naming -- which was handled last week
<fjh> ISSUE-155?
<trackbot> ISSUE-155 -- Enable Feature Detection -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/155
<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
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
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
RESOLUTION: Adopt proposal associated with ACTION-652: http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0003.html
<fjh> ACTION: anssik to update Vibration draft per ACTION-652 [recorded in http://www.w3.org/2013/10/10-dap-minutes.html#action01]
<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]
<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
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
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, 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, 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]
<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
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]
<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
<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/
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
<fjh> Web & TV IG review in progress
<fjh> wiki http://www.w3.org/2009/dap/wiki/NSD_Security
<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
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