See also: IRC log
<trackbot> Date: 04 September 2013
<scribe> ScribeNick: fjh
Reminder: No DAP F2F at TPAC, but there will be the Media Capture TF meeting, please attend that.
fjh: if you are attending TPAC please remember to register and make arrangements soon
a new Working Draft of Media Capture and Streams has just been published: http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903/ ; http://www.w3.org/TR/mediacapture-streams/
Approve minutes from 21 August 2013
http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0048/minutes-2013-08-21.html
RESOLUTION: Minutes from 21 August 2013 are approved
LC-2739 http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0055.html
Proximity CR CfC (5 Sept deadline) http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0054.html
Light CR CfC (5 Sept deadline) http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0056.html
using WebIDL's "conforming IDL fragment" conformance class (Barstow, http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0059.html)
fjh: CfC deadline is tomorrow, +1 on list would be useful
... dom responded to Art that what we are doing makes sense
anssik: will look at this
http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0061.html
Remaining questions/comments:
Question/Comment on CR draft: http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0050.html
Question Vibration and iframes, http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0055.html
Question: Vibration strength http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0040.html
Supporting strength (Marcos) http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0062.html
fjh: anssik, can you please review these and respond on the list.
... I think most are editorial
... I believe the WG is deciding to defer vibration sstrength
... I would think vibration would only be active for the active window
anssik: fix would be to say top level browsing context
fjh: that makes sense to me, thought you already made that change
anssik: did it for proximity
fjh: I think we should be consistent
anssik: this is a generic issue
fjh: I think we should make this change in the editors draft, pull it in in PR
anssik: walks through choices, looking at mail http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0055.html
fjh: clarification needed
... would relate to the other strength issues
<scribe> ACTION: anssik to make proposal on list regarding multiple vibration API invocations in frames for Vibration [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action01]
<trackbot> Created ACTION-652 - Make proposal on list regarding multiple vibration api invocations in frames for vibration [on Anssi Kostiainen - due 2013-09-11].
fjh: re vibration strength, Marcos suggested in next version, http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0062.html
anssik: do we have a concrete proposal
fjh: no
RESOLUTION: defer Vibration strength to next version of Vibration API
anssik: ask for discussion on list, most implementations currently do not support strength
another clarification issue http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0050.html
<scribe> ACTION: fjh to create issues for Vibration questions [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action02]
<trackbot> Created ACTION-653 - Create issues for vibration questions [on Frederick Hirsch - due 2013-09-11].
fjh: WD for publication in progress, Rich created draft, I had some comments, awaiting resolution before publication
Web & TV IG review, http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0063.html
fjh: want to have published WD for review
... reopened issue, difficult to resolve without everyone on call
Re-Opened ISSUE-130, see http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0053.html (discuss next week 4 Sept)
ISSUE-131 comment, http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0066.html (Tatsuya Igarashi )
ISSUE-148?
<trackbot> ISSUE-148 -- NetworkService.name definition in 8.2.2.4 incoherent with definition in 7.1 (a human-readable title for the service) -- raised
<trackbot> http://www.w3.org/2009/dap/track/issues/148
jcdufound: regarding ISSUE-148, agreed between Jean-Claude and Cathy but Rich might have missed part of this discussion
… service type for SDP is not human-readable at all
… agree with Cathy that should change to something with friendly name of the device, believe Rich disagrees due to possible fingerprinting issue
… not a fingerprinting issue, since only exposed after authorization step
fjh: could still be fingerprinting despite authorization
jcdufourd: should make this change once we have agreement with Rich
ISSUE-130?
<trackbot> ISSUE-130 -- Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/130
jcdufourd: need answer to my argument on the list from richt
… need to determine what is appropriate in the use case I presented, which would require large number of discovery requests
… I implemented current state of spec, others implemented services
… they didn't want to use complete name each time, wanted one search regardless of the protocol
… didn't care about underlying discovery protocol
… so search with fragments
… requests from authors to simply API
… that is the main point to make it use simpler for authors
cathy: issue with doing that, web app might not be able to handle all the responses that come back
… different types of media renderers
… so get everything and filter on what you can use versus ask for what you can get
… I think it might make sense to ask what you can process
… I think rich agrees
… for media renders can have same service name with different domain and protocol, so can get services you cannot handle
fjh: can this be done with a wrapper, convenience function?
jcdufourd: tried this first with adaptation layer, but could not do it
… however could modify my implementation to allow for it
… with small change
fjh: why not offer both options
jcdufourd: ok with me
cathy: first need to decide what we want
… if UA does not continuously monitor then problem
… UPnP does not allow wild card services
fjh: why didn't jclaude have this problem
cathy: monitors network, doesn't do search
fjh: issue search vs continues monitored
... wonder if we can allow support for implementation that can handle it but not for implementation that cannot
... e.g. allow for usability where it makes sense and can be supported in underlying implementation but otherwise not
<Cathy> http://www.w3.org/2009/dap/track/issues/130
fjh: this way we do not create an artificial limitation where not needed
cathy: might be hard to spec
jcdufourd: we could have an exception if implementation does not support it
<Josh_Soref> i'm not in favor of this
fjh: is it possible or necessary to have a different wildcard api method so developer knows what to expect
... summary, trying to enable usability where implementation supports it yet not get into difficulty where implementation does not
josh_soref: do not want same API used for both, will work in test environment but not in another case, will have interop problem
fjh: have two APIs
josh_soref: would only use wildcard api if you know you really want to, have fallback path
… so don't see this as a big problem for developers
jcdufourd: developer needs feature detection to see if can use wildcard api, otherwise fallback
josh_soref: one way is to not have function present if not implemented
fjh: i think the next step is to draft some specification text and use that to drive some more discussion
<scribe> ACTION: jcdufourd to propose text for Network Service Discovery to define wildcard API and feature detection [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action03]
<trackbot> Error finding 'jcdufourd'. You can review and register nicknames at <http://www.w3.org/2009/dap/track/users>.
<scribe> ACTION: Dufourd to propose text for Network Service Discovery to define wildcard API and feature detection [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action04]
<trackbot> Created ACTION-654 - Propose text for network service discovery to define wildcard api and feature detection [on Jean-Claude Dufourd - due 2013-09-11].
ISSUE-131?
<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/131
email message http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0002.html
cathy: general concern is about complexity added to spec
… if device string is UPnP specific so we lose generic aspec
igarashi: won't be too complicated, similar api
… device type is more important than service type
fjh: why more important
igarashi: based on UPnP architecture, first find by device then service type
fjh: seems to be another issue related to trying to make underlying discovery mechanism transparent
igarashi: cannot be agnostic to underlying discovery mechanism, not a goal
clarke: one goal was to be agnostic, approach is to use parameters to allow UA to deal with specifics, customization
fjh: what is the minimal set of changes we can make to the spec, then we can discuss
cathy: it is in the issue text
fjh: not sure that is the minimum
igarashi: we can offer a proposal on the list
fjh: anything more on this topic?
Update on testing, http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0065.html
thanks for this work to Intel
Proposal: Changing meeting time from Wed to Thur (same time), https://lists.w3.org/Archives/Member/member-device-apis/2013Aug/0000.html
<anssik> Thu is ok for me
<anssik> earlier is better
<anssik> conflict on Tue
fjh:
<Josh_Soref> thursday is good for me, i've already moved my schedule around for it to fit
RESOLUTION: Recurring meeting moved to Thursdays, same time (10 am ET)
and also
RESOLUTION: cancel 24 Oct, 28 Nov and 26 Dec
<Josh_Soref> regrets for Thursday September 19 and September 26 :)
<Josh_Soref> ... Sukkot
ACTION-621?
<trackbot> ACTION-621 -- Anssi Kostiainen to Create test cases for HTML Media Capture -- due 2013-03-13 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/621
ACTION-621: resolved with http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0065.html
<trackbot> Notes added to ACTION-621 Create test cases for HTML Media Capture.
close ACTION-621
<trackbot> Closed ACTION-621.
ACTION-643?
<trackbot> ACTION-643 -- Anssi Kostiainen to Review Ambient Light and Proximity test cases by Sept -- due 2013-07-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/643
anssik: done
close ACTION-643
<trackbot> Closed ACTION-643.
<anssik> https://dvcs.w3.org/hg/dap/rev/916dbd5920d8
<scribe> ACTION: anssik to update test for light :https://dvcs.w3.org/hg/dap/rev/916dbd5920d8 [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action05]
<trackbot> Created ACTION-655 - Update test for light :https://dvcs.w3.org/hg/dap/rev/916dbd5920d8 [on Anssi Kostiainen - due 2013-09-11].
<anssik> https://dvcs.w3.org/hg/dap/rev/a6ad49819c41
<scribe> ACTION: anssik to update proximity test for https://dvcs.w3.org/hg/dap/rev/a6ad49819c41 [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action06]
<trackbot> Created ACTION-656 - Update proximity test for https://dvcs.w3.org/hg/dap/rev/a6ad49819c41 [on Anssi Kostiainen - due 2013-09-11].
action-649?
<trackbot> action-649 -- Anssi Kostiainen to Review todo items associated with battery test cases -- due 2013-08-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/649
fjh: todo items were removed
close ACTION-649
<trackbot> Closed ACTION-649.
action-621?
<trackbot> action-621 -- Anssi Kostiainen to Create test cases for HTML Media Capture -- due 2013-03-13 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/621
action-647?
<trackbot> action-647 -- Frederick Hirsch to Send cfc to progress light to cr, two week cfc -- due 2013-08-21 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/647
close ACTION-647
<trackbot> Closed ACTION-647.
close ACTION-648
<trackbot> Closed ACTION-648.
anssik: may need updates for IDLharness tests for battery
<scribe> ACTION: anssik to revise battery tests for IDLharness, find QA person to help [recorded in http://www.w3.org/2013/09/04-dap-minutes.html#action07]
<trackbot> Created ACTION-657 - Revise battery tests for idlharness, find qa person to help [on Anssi Kostiainen - due 2013-09-11].
reviewed network service discovery issues during call
<scribe> New editors draft of getUserMedia, http://dev.w3.org/2011/webrtc/editor/archives/20130824/getusermedia.html
fjh: is there any relevant news from sys apps f2f relevant to dap
anssik: no dap relevant discussions
<Josh_Soref> SysApps asked to change their TPAC F2F dates
<Josh_Soref> ... because they were initially avoiding DAP
<Josh_Soref> ... but w/o DAP, they're now trying to avoid WebApps instead
<Josh_Soref> ... it's unclear if they'll succeed
Next week we will meet at new meeting day, Thursday, please remember to update your calendars.