See also: IRC log
<trackbot> Date: 03 July 2013
<scribe> scribeNick: fjh
fjh: "MediaStream Image Capture" CfC concluded with no objection to FPWD publication, http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0018.html
dom: planned for 9 july publication
fjh: 31 July teleconference cancelled (chair not available)
Approve minutes from 5 June 2013
http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/att-0016/minutes-2013-06-05.html
<dom> (Regrets from me on July 17, 24)
RESOLUTION: Minutes from 5 June 2013 are approved
LC (23 May - 13 June), http://www.w3.org/TR/2013/WD-vibration-20130523/
Disposition of comments, https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-vibration-20130523/doc/
Clarification of Introduction (6 Jun) http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0010.html
Revision of processing steps (12 Jun) http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0014.html
<dom> (definitely)
<Josh_Soref> scribe: Josh_Soref
<fjh> fjh: next step should be CR transition, awaiting confirmation to close LC comment
fjh: i'd like to go to CR ASAP
... if i hear nothing within two weeks, i'll close this DoC comment out
... i don't think there's a rush here
... testcases can go on
... comments anssik ?
anssik: no comments/concerns
... you covered the changes
fjh: dom, do we need to do any special stuff? we've been to CR before
dom: we need a Transition Request
... but i don't think we need a Transition Call
<fjh> ACTION: fjh to send Vibration CR CfC and make transition request once LC disposition complete [recorded in http://www.w3.org/2013/07/03-dap-minutes.html#action01]
<trackbot> Created ACTION-639 - Send Vibration CR CfC and make transition request once LC disposition complete [on Frederick Hirsch - due 2013-07-10].
dom: once there Request is drafted, i can work with you on making it clear that we don't need a call as such
<fjh> http://www.w3.org/2011/07/DeviceAPICharter
fjh: i don't think it's been extended yet
dom: it's in process
... if all goes as planned, i think we'll get the extension next week
<fjh> Simplification proposal: http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0015.html (Jean-Claude)
<fjh> Open Source implementation: http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0009.html (Jean-Claude)
<fjh> Earlier comments and issues, status: http://lists.w3.org/Archives/Public/public-device-apis/2013May/0028.html
gmandyam: the two independent implementations is an unwritten rule
... we had Opera under its old engine do an implementation
... and we have jcd doing an implementation
... do we need a Firefox/similar implementation?
fjh: i think we have two
dom: my recollection was that we agreed that for recommendations targeted at browsers
... we wanted implementations in major shipping browsers
Josh_Soref: +1
fjh: thank you dom for remembering that
... but i think we should be appreciative of jcd's work
<fjh> Single interface to expose both state and value: - http://lists.w3.org/Archives/Public/public-device-apis/2013May/0008.html
<fjh> proposal - CfC to accept Anssi's proposed resolution? http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0043.html
fjh: i'm wondering...
... should i send a CfC to accept anssik 's proposed resolution?
... what are we waiting for?
... anssik what do you suggest at this point?
anssik: i haven't talked w/ dougt about this
... i noticed that Firefox 22 shipped an api for ambient light (in Lux)
... on OS X
<anssik> https://developer.mozilla.org/en-US/docs/Web/API/DeviceLightEvent
anssik: it's something shipping in the desktop firefox which has significant marketshare
... so that means we keep the DeviceLight interface intact
... and probably merge the other interface with that one
fjh: it's not necessary
<dom> (well, if it's only on MacOS X, I'm not sure it's such a big market share)
fjh: we could keep our current design
anssik: if we keep our current interface, it's what's shipping in Desktop in OS X
... the suggestion initially by anne was to merge Light-Level with that Interface
... i think we're still on track
fjh: is this a matter of taste, or efficiency?
... is there a reason to make a change whatsoever?
anssik: it's a matter of API design
... developer ergonomics
... and a bit of taste
<anssik> http://anssiko.github.io/light/
anssik: i wanted to test this out
... if you have Firefox 22+ on OS X, you can try the demo
... i noticed that the light level doesn't expose dim-normal-bright
<anssik> https://bugzilla.mozilla.org/show_bug.cgi?id=842952
anssik: the guy who was supposed to work on merging the interfaces in terms of implementation
... said he changed jobs and can't work on this
... so it would take a while for mozilla to get to this
fjh: if we don't merge, isn't Firefox closer to what we have now?
anssik: what Firefox implements is just part of the spec
... there's still a migration path
... we could still merge the interfaces and the implementation would be compliant
fjh: so, i sense that making your proposed change would be premature
anssik: it would be good to give Mozilla a bit more time
... and i'd be happy to hear developer feedback
... now that the device-light-event part is available to developers
... Firefox for OS X might be on millions of computers
... this is also shipping in Firefox OS
<fjh> http://www.w3.org/Privacy/
anssik: and Firefox on Android
... and it was recently enabled on Firefox desktop on OS X
... because you need platform adaptation, on desktops this is currently only on OS X
<anssik> impl status: https://developer.mozilla.org/en-US/docs/Web/API/DeviceLightEvent#Gecko-specific_notes
fjh: Another reason to give this time is I anticipate additional feedback from the PING, privacy interest group, on these specs
... also have messages from Nick and Rigo
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013May/0046.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0012.html
anssik: it sounds reasonable to wait
... and collecting input from PING
<fjh> ACTION: fjh to respond to Nick and Rigo re privacy concerns in Proximity, Light [recorded in http://www.w3.org/2013/07/03-dap-minutes.html#action02]
<trackbot> Created ACTION-640 - Respond to Nick and Rigo re privacy concerns in Proximity, Light [on Frederick Hirsch - due 2013-07-10].
<fjh> ACTION-640: http://lists.w3.org/Archives/Public/public-device-apis/2013May/0046.html
<trackbot> Notes added to ACTION-640 Respond to Nick and Rigo re privacy concerns in Proximity, Light.
<fjh> ACTION-640: http://lists.w3.org/Archives/Public/public-device-apis/2013Jun/0012.html
<trackbot> Notes added to ACTION-640 Respond to Nick and Rigo re privacy concerns in Proximity, Light.
dom: until we know what process needs to be followed to get this approved, it won't be approved
<fjh> Waiting for pull requests to be accepted - who is doing this?
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013May/0076.html
<fjh> Test case submission, approval process (and licensing requirements) http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0002.html
dom: there was a discussion of having someone from each WG having commit privs
... and having someone else from the WG review each testcase before pulling
... this has been a fluctuating conversation, so it's been difficult for me
[ Discussion about Test Case evolution v. Recommendation evolution ]
fjh: i think it's good to have testcases in the repository
... but we know where the testcases are coming from since anssik has been doing all the curating for a while
... are the testcases in a suitable state to pull into the GIT repo?
anssik: i thought there was a review process
... so someone other than the submitter should review the tests
<dom> battery is from anssik, vibration from robin, ambient light and proximity from marcosc,
dom: i reviewed the battery tests from anssik a while ago
... and the vibration tests from robin a while ago
... i don't know that anyone has looked at ambient light/proximity
anssik: i initially looked at the tests when marcos submitted them
<dom> ACTION: Dom to do a last check on battery and vibration test cases before merging in github master [recorded in http://www.w3.org/2013/07/03-dap-minutes.html#action03]
<trackbot> Created ACTION-641 - Do a last check on battery and vibration test cases before merging in github master [on Dominique Hazaël-Massieux - due 2013-07-10].
anssik: now that we have an implementation out, we could actually harness
... iirc, marcos didn't use idlharness, but basically drafted something similar
<dom> ACTION: Dom to review proximity and ambient light test cases [recorded in http://www.w3.org/2013/07/03-dap-minutes.html#action04]
<trackbot> Created ACTION-642 - Review proximity and ambient light test cases [on Dominique Hazaël-Massieux - due 2013-07-10].
<dom> https://github.com/w3c/web-platform-tests/pull/127
anssik: i think you can use +1'ing on github
<dom> https://github.com/w3c/web-platform-tests/pull/126
<dom> https://github.com/w3c/web-platform-tests/pull/125
<dom> https://github.com/w3c/web-platform-tests/pull/124
fjh: i'm confused about tests that aren't easily visible in the repo
... i thought the concern was about improving visibility
dom: yes, ideally the testcases would be merged
<fjh> ACTION: anssik to review Ambient Light and Proximity test cases by Sept [recorded in http://www.w3.org/2013/07/03-dap-minutes.html#action05]
<trackbot> Created ACTION-643 - Review Ambient Light and Proximity test cases by Sept [on Anssi Kostiainen - due 2013-07-10].
dom: i don't think there's any particular hurry
... they should be merged when we exit CR
... it's clear we need a plan to have them reviewed
<fjh> Test case submission, approval process (and licensing requirements) http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0002.html
fjh: i don't know if W3C is enforcing licensing for contributions
dom: the licensing is only problematic for non WG contributors
... which hasn't been a problem for our WG
<fjh> Request for implementation status, http://lists.w3.org/Archives/Public/public-device-apis/2013May/0069.html
anssik: we're currently working to get Chrome for Android's HTML Media Capture updated
... it seems we're reaching consensus
... so we'll get the patches upstreamed
... once that happens, i can update you on that
fjh: what consensus is needed?
<anssik> https://codereview.chromium.org/14758008/
anssik: there was concern from Google that it would break existing content
... we reached a conclusion that we could have an implementation strategy that retains backwards compat with existing code
<fjh> ACTION-523?
<trackbot> ACTION-523 -- Anssi Kostiainen to work on test cases for battery, vibration, and HTML Media Capture -- due 2012-08-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/523
<fjh> ACTION-621?
<trackbot> ACTION-621 -- Anssi Kostiainen to create test cases for HTML Media Capture -- due 2013-03-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/621
<fjh> ACTION-637?
<trackbot> ACTION-637 -- Dominique Hazaël-Massieux to arrange for DAP charter extension, per http://lists.w3.org/Archives/Public/public-device-apis/2013May/0078.html -- due 2013-06-12 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/637
<fjh> ACTION-625?
<trackbot> ACTION-625 -- Dominique Hazaël-Massieux to move DAP tests to Git, with help from others as needed -- due 2013-05-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/625
<fjh> close ACTION-625
<trackbot> Closed ACTION-625 Move DAP tests to Git, with help from others as needed.
<fjh> close ACTION-635?
<trackbot> Closed ACTION-635 Check on Media Capture TPAC F2F plans.
<fjh> close ACTION-636
<trackbot> Closed ACTION-636 Send public list regarding consensus regarding charter extension.
<fjh> close ACTION-638
<trackbot> Closed ACTION-638 Review webapps approach to reviewing test cases.
<fjh> ISSUE-128?
<trackbot> ISSUE-128 -- Need more description on how bandwidth should be estimated -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/128
anssik: i'll be on vacation during the summer
fjh: i'm canceling July 31
... but i'll cancel other calls when there's isn't content for meetings
<Zakim> dom, you wanted to ask about August
dom: i can't remember if we tend to cancel in August
fjh: i don't think we did
... it depends on the makeup of the group
... some are in the US, some aren't
... some are on vacation, some aren't
... i'm hoping to have an agenda for TPAC to give people time to make travel decisions
... dom, are you away in August?
dom: i'll be away a couple of weeks at the end
fjh: anssik, you're back?
anssik: i'm back August 10th
fjh: if Cathy and Rich are available, maybe it's worth having a call to move that spec forward
dcheng3: i agree, it would be good to have calls to tackle the topics that have been lagging behind
... i won't take many holidays in August, maybe a week
fjh: we won't make decisions without the right people on calls
... i guess i won't make CfCs in August
... thanks all
... if people want to send Regrets to the Member List
... that could help me
fjh: thanks everyone for your time
... see you next week, if we have a call