[![W3C](http://www.w3.org/Icons/w3c_home)](http://www.w3.org/) # - DRAFT - # Device APIs Working Group Teleconference ## 09 Jan 2013 [Agenda](http://lists.w3.org/Archives/Public/public-device- apis/2013Jan/0009.html) See also: [IRC log](http://www.w3.org/2013/01/09-dap-irc) ## Attendees Present Anssi_Kostiainen, Bryan_Sullivan, Cathy, Diana_Cheng, Dzung_Tran, Frederick_Hirsch, Josh_Soref, Laszlo_Gombos, Milan_Patel, dom Regrets Chair Frederick_Hirsch Scribe Josh_Soref ## Contents * Topics 1. Announcements 2. Minutes Approval 3. HTML Media Capture 4. Ambient Light - LC 5. Proximity API - LC 6. General LC comment (putting Ambient Light/Proximity into single document) 7. Network Service Discovery 8. Magnetic Field Events 9. Upcoming meetings 10. Action Review 11. AOB 12. Adjourn * Summary of Action Items * * * Date: 09 January 2013 scribe: Josh_Soref ### Announcements Happy New Year all. Welcome Sunghan - [http://lists.w3.org/Archives/Public/public-device- apis/2013Jan/0007.html](http://lists.w3.org/Archives/Public/public-device- apis/2013Jan/0007.html) ### Minutes Approval 12 December 2012 - [http://lists.w3.org/Archives/Public/public-device-ap is/2012Dec/att-0073/minutes-2012-12-12.html](http://lists.w3.org/Archives/Publ ic/public-device-apis/2012Dec/att-0073/minutes-2012-12-12.html) **RESOLUTION: Draft minutes from 12 December 2012 are approved.** ### HTML Media Capture working draft published 13 December 2012: [http://www.w3.org/TR/2012/WD- html-media-capture-20121213/](http://www.w3.org/TR/2012/WD-html-media- capture-20121213/) fjh: ... with the change to the boolean previous LC Draft Comments [https://www.w3.org/2006/02/lc-comments- tracker/43696/WD-html-media-capture-20120712/doc/](https://www.w3.org/2006/02 /lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/) await Doug Scheper's confirmation: [http://lists.w3.org/Archives/Public /public-device-apis/2013Jan/0008.html](http://lists.w3.org/Archives/Public /public-device-apis/2013Jan/0008.html) fjh: dom, when you see shepazu... dom: i'll try to ping him, i should see him next week fjh: i think we've done a good job, but i'd like his confirmation ... once that's done, i think we've addressed all the LC comments ... AnssiK did you want to say anything? AnssiK: we got positive feedback from Facebook (tobie) and Mozilla (mounir) ... we should try to ping the Google guys fjh: AnssiK can you please send an email AnssiK: yes, I ca fjh: I think we are on the right track, given that the LC comments were resolved with our recent changes ### Ambient Light - LC LC published 13 December 2012, [http://www.w3.org/TR/2012/WD-ambient- light-20121213/](http://www.w3.org/TR/2012/WD-ambient-light-20121213/) LC ends 26 January. LC comments (3 specific + 1 general comment so far) [https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient- light-20121213/](https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- ambient-light-20121213/) fjh: there's comments about default values ... i think AnssiK replied there ... there are specific comments from tabatkins AnssiK: dougt is editing the spec ... i've asked if he'd like me to help him **ACTION:** anssiK to update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action01](http://www.w3.org/2013/01/09-dap- minutes.html#action01)] Created ACTION-605 - Update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light [on Anssi Kostiainen - due 2013-01-16]. fjh: will you also deal w/ event-member? ... that seems to be a general comment [https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient- light-20121213/2738](https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- ambient-light-20121213/2738) fjh: for other specs too general comment to Proximity and Ambient Light AnssiK: that's part of this [https://dvcs.w3.org/hg/dap/log/4a9ad5688160/proximity/Overview.html] (https://dvcs.w3.org/hg/dap/log/4a9ad5688160/proximity/Overview.html) AnssiK: i'll cherrypick anne's comments ... from proximity and backport them into ambient light **ACTION:** anssik to update Proximity and Ambient Light to define events, per LC-2738 [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action02](http://www.w3.org/2013/01/09-dap- minutes.html#action02)] Created ACTION-606 - Update Proximity and Ambient Light to define events, per LC-2738 [on Anssi Kostiainen - due 2013-01-16]. AnssiK: that should be fairly straightforward [https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient- light-20121213/2738](https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- ambient-light-20121213/2738) fjh: will you do this as well? AnssiK: this will be handled fjh: send me a pointer if there's anything else i haven't recorded AnssiK: you've probably updated it already, but i'll double check **ACTION:** anssik to update Ambient Light per LC-2737, bringing any questions to the list [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action03](http://www.w3.org/2013/01/09-dap- minutes.html#action03)] Created ACTION-607 - Update Ambient Light per LC-2737, bringing any questions to the list [on Anssi Kostiainen - due 2013-01-16]. ### Proximity API - LC LC published 6 December 2012. LC ends 24 January. LC comments (2 specific comments , 1 general comment so far) : [https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- proximity-20121206/](https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- proximity-20121206/) AnssiK: that's already addressed [https://www.w3.org/2006/02/lc-comments-tracker/43696/WD- proximity-20121206/2731](https://www.w3.org/2006/02/lc-comments-tracker/43696 /WD-proximity-20121206/2731) [https://dvcs.w3.org/hg/dap/raw- rev/52acb4877e86:](https://dvcs.w3.org/hg/dap/raw-rev/52acb4877e86:) [https:// dvcs.w3.org/hg/dap/rev/52acb4877e86](https://dvcs.w3.org/hg/dap/rev/52acb4877e 86) **ACTION:** fjh to update LC-2731 as completed [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action04](http://www.w3.org/2013/01/09-dap- minutes.html#action04)] specify the interface name in the definition of default values i.e. 'The XXX attribute of the YYY interface MUST […]': [https://dvcs.w3.org/hg/dap /rev/6507cb51ce47](https://dvcs.w3.org/hg/dap/rev/6507cb51ce47) Created ACTION-608 - Update LC-2731 as completed [on Frederick Hirsch - due 2013-01-16]. fjh: so both of these are done? AnssiK: yes, you can close them ... i'll need to update ambient accordingly, but for proximity, they're done ### General LC comment (putting Ambient Light/Proximity into single document) fjh: earlier, we had a generic sensor api ... i think the comments here are asking for something else ... i think rick is proposing ... is to have a spec for ambient/proximity as one spec ... but for a bunch of things that have the same api shape ... there's some positives and negatives to making such a change ... it's good to avoid duplication when you can ... advantage of splitting up is you can go forward on individual timelines [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0052.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0052.html) (Anne) [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0059.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0059.html) (detailed, Rick) [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0066.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0066.html) - device namespace editing offer: [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0060.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0060.html) (Rick) fjh: it depends on what implementers think/want ... previously we discussed a generic sensor API that was broad and extensible, I believe this proposal has narrower scope to those well-defined items that have common mechanism such as Ambient Light, Proximiity originally we have many of these sensors in one spec; the group want to split them fjh: in general agree it is good to avoid repetition of material, express common material once ... however from process perspective advantages to having separate tracks ... would like to avoid backtracking in process, e.g. back to FPWD etc AnssiK: what anne said is it would be easier to review if the specs were merged together ... notes two issues - how to organize specs versus different design ... and there was less boilerplate ... if other factors make things worse fjh: maybe we should first deal w/ the issue of whether we have the right design ... i'd like to hear if there's a problem we need to address Josh_Soref: one concern - if we have something with an API that is abstracted, what does it mean to have two implementations. ... clear for proximity but not in generic case ... fantasi publishes annual compendiums of CSS specs, likewise for WHATWG specs ... compendium is spec that is implemented ... still allows them to move forward need to be clear what is authoritative [Cascading Style Sheets (CSS) Snapshot 2010](http://www.w3.org/TR/CSS/) (W3C Working Group Note 12 May 2011) AnssiK: i could easily hack that in ... we could easily product such a document out of what we have today [that seems to be still orthogonal to fjh's question about design rather than packaging] [https://dvcs.w3.org/hg/dap/raw-file/tip/sensor- api/Overview.html](https://dvcs.w3.org/hg/dap/raw-file/tip/sensor- api/Overview.html) fjh: you were concerned about how do you know if you've implemented it ... if each thing is defined in the spec individually, then it's still line items this was originally the package of all the sensors fjh: we define them together ... you're right, that otherwise it's untestable ... on your second point ... we could do that ... as a compendium ... as AnssiK says, a NOTE ... that might be a good solution dom: before we worry about packaging ... there's a high level design question ... what rick was asking for is a change from what we have today ... Constructors ... how you access them, how they're exposed ... that's a fairly strong departure from what we've been doing to be concrete, is this the correct design discussion reference, [http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0060.html](http://lists.w3.org/Archives/Public/public-device- apis/2012Dec/0060.html) dom: the main question before we worry about how we package them together ... is whether we should change the current, widely deployed, api ... yes, that link fjh: there's a tension between what's implemented, and what could be better/not AnssiK: the current designs are implementer driven we experimented with constructor in some early Battery Status API drafts, e.g.: [http://www.w3.org/TR/2011/WD-battery- status-20110915/](http://www.w3.org/TR/2011/WD-battery-status-20110915/) AnssiK: we experimented with structured patterns ... and that was shot down based on implementers' feedback ... it had something to do with making the api as simple as possible question is whether there are essential use cases not addressed in current approach AnssiK: we've been there, done that, it didn't work with battery ... it has something to do with defining default state ... how do you measure state changes ... if you have a constructor, you start monitoring state when you construct it lgombos: question of whether it is just consistency and syntactic sugar or whether there is a fundamental change, if just consistency a library could be built on top of what we have defined ... if things are apis in a certain way, libraries can always provide that ... i think the issue is any functional change dom, you wanted to say we need to document our design and hopefully reply to the thread dom: i don't have an answer on whether we should change this ... going to implementers and telling them we're getting input from developers ... that developers think the current approach is wrong/not easy to track we need to make a clear decision with agreement from implementers dom: we need to make an explanation of our current approach and well as a justification of why a change might be desired, so a decision can be made and agreed ... we should go back to the implementers/developers AnssiK: we have 2 implementations ... afaik, we have no shipping implementations ... you can probably build firefox with proximity on ... some webkit ports have implemented proximity ... from this perspective, it would be possible to change the design ... without breaking the web ... the other question is whether implementers will get upset ... what is the problem that the new design fixes that the old design doesn't ... default-state is solved by constructor we need to summarize the focus point of the advantages of each approach AnssiK: dougt is a proponent of simplicity ... i'd love to hear dougt's reasoning Josh_Soref: in theory it might be possible to change API before it ships, but implementers would prefer not to change code that is already written, due to amount of work before shipping ... everyone is trying to move fast without rework ... whether the changes are good or not, it still might be hard to obtain implementation. need a very convincing argument fjh: we need to make a good case about what the proposal really means ... rick offered to write a spec ... maybe someone could write a summary of why it's important ... what exactly is the deficiency ... we need a proposal about why it's necessary ... i'm not sure i understand, apart from the surface change, what we get ... i'll ask rick AnssiK: i'm assuming mozilla is working on this api because they need it for their os ... and for their UC, it's working **ACTION:** fjh to ask Rick to make proposal for change, summarizing use cases and benefits of change [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action05](http://www.w3.org/2013/01/09-dap- minutes.html#action05)] Created ACTION-609 - Ask Rick to make proposal for change, summarizing use cases and benefits of change [on Frederick Hirsch - due 2013-01-16]. AnssiK: you should question the UCs this current api doesn't address ... it'd be better if rick tries to build his stuff on B2G ... to show how his concerns aren't just a stylistic thing, but are a functional gap fjh: agreed ... AnssiK, if you want to summarize to the list AnssiK: for the record, i'm indifferent on the design ... i'm mostly interested in consensus ### Network Service Discovery [http://www.w3.org/TR/2012/WD-discovery- api-20121004/](http://www.w3.org/TR/2012/WD-discovery-api-20121004/) fjh: i think we need richt for this ... not sure if Cathy has thoughts on this Cathy: i think there are questions/comments for richt ... i think he said that he was working on the mDNS section ... i think we need to wait for him to come back to us **ACTION:** fjh to contact Richt offline re network service discovery [recorded in [http://www.w3.org/2013/01/09-dap- minutes.html#action06](http://www.w3.org/2013/01/09-dap- minutes.html#action06)] Created ACTION-610 - Contact Richt offline re network service discovery [on Frederick Hirsch - due 2013-01-16]. ### Magnetic Field Events [https://wiki.mozilla.org/Magnetic_Field_Events](https://wiki.mozilla.or g/Magnetic_Field_Events) fjh: question of whether we should be doing this in this group ... anyone have any comment on it? sounds OK to me, can we start a wiki for use cases at least? dom: my reading of the charter says that it's in scope ... but it'd be useful to have UCs and Reqs +1 to start with UCs fjh: next step is to determine what this is for I'll respond on the list asking for use cases fjh: i'll respond on the list ### Upcoming meetings F2F - 9-10 April, Location to be determined. Please indicate offers to host. fjh: i mentioned Burlington, MA ... bryan mentioned Seattle or Redmond ... if people are considering being able to host ... they could indicate on the list fairly soon [ F2F - 9-10 April ] fjh: probably need to pick a spot by next week to give organizers lead time [should you re-send a call for hosts to member-device-apis, fjh?] bryan: let me confirm i can get a large enough room dcheng3: i can probably get an answer by next week ... 20-30 people? ... any other requirements? **RESOLUTION: Meeting Jan 30 is canceled** ### Action Review [http://www.w3.org/2009/dap/track/actions/open](http://www.w3.org/2009/d ap/track/actions/open) [http://www.w3.org/2009/dap/track/actions/pendingreview](http://www.w3.o rg/2009/dap/track/actions/pendingreview) ### AOB fjh: thanks all, happy new year ... AnssiK has actions for ambient light/proximity ... i have actions to update proposals Josh_Soref: RTCWeb/WebRTC/MC has a working week there will be considerable discussion of media capture in that meeting fjh: it's in the burlington area (?) ... Feb 5-7 (?) We will attend (Dan Druta) fjh: i think MC is on the 5th (?) dom: MC will be a main topic for the WebRTC part of the meeting ... probably on 5-6 ... chairs are still refining fjh: Josh_Soref, thanks for mentioning that Bedford dom: it's Bedford, MA hosted by ACME Packet Actions on Anssi to update specs, fjh to reply on list and ask for proposal from Rick, potential f2f hosts to check on hosting [Media Capture F2F during WebRTC/RTCWeb meetings](http://lists.w3.org/Archives/Public/public-media- capture/2012Nov/0091.html) ### Adjourn trackbot, end meeting ## Summary of Action Items **[NEW]** **ACTION:** anssik to update Ambient Light per LC-2737, bringing any questions to the list [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action03](http://www.w3.org/2013/01/09-dap-minutes.html#action03)] **[NEW]** **ACTION:** anssiK to update Ambient Light specification for LC-2737 , bringing queueing order update from Proximity to Ambient Light [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action01](http://www.w3.org/2013/01/09-dap-minutes.html#action01)] **[NEW]** **ACTION:** anssik to update Proximity and Ambient Light to define events, per LC-2738 [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action02](http://www.w3.org/2013/01/09-dap-minutes.html#action02)] **[NEW]** **ACTION:** fjh to ask Rick to make proposal for change, summarizing use cases and benefits of change [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action05](http://www.w3.org/2013/01/09-dap-minutes.html#action05)] **[NEW]** **ACTION:** fjh to contact Richt offline re network service discovery [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action06](http://www.w3.org/2013/01/09-dap-minutes.html#action06)] **[DONE]** **ACTION:** fjh to update LC-2731 as [recorded in [http://www.w3.org/2013/01/09-dap-minutes.html#action04](http://www.w3.org/2013/01/09-dap-minutes.html#action04)] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl](http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm) version 1.137 ([CVS log](http://dev.w3.org/cvsweb/2002/scribe/)) $Date: 2012-09-20 20:19:01 $