Device APIs Working Group Teleconference -- 09 Jan 2013

<trackbot> Date: 09 January 2013

<scribe> scribe: Josh_Soref

Announcements

<fjh> Happy New Year all.

<fjh> Welcome Sunghan - http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0007.html

Minutes Approval

<fjh> 12 December 2012 - http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/att-0073/minutes-2012-12-12.html

RESOLUTION: Draft minutes from 12 December 2012 are approved.

HTML Media Capture

<fjh> working draft published 13 December 2012: http://www.w3.org/TR/2012/WD-html-media-capture-20121213/

fjh: ... with the change to the boolean

<fjh> previous LC Draft Comments https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/

<fjh> await Doug Scheper's confirmation: 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> fjh: I think we are on the right track, given that the LC comments were resolved with our recent changes

Ambient Light - LC

<fjh> LC published 13 December 2012, http://www.w3.org/TR/2012/WD-ambient-light-20121213/

<fjh> LC ends 26 January.

<fjh> LC comments (3 specific + 1 general comment so far) 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

<fjh> 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]

<trackbot> 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

<fjh> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-ambient-light-20121213/2738

fjh: for other specs too

<fjh> general comment to Proximity and Ambient Light

AnssiK: that's part of this

<AnssiK> 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

<fjh> 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]

<trackbot> 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

<fjh> 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

<fjh> 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]

<trackbot> 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

<fjh> LC published 6 December 2012. LC ends 24 January.

<fjh> LC comments (2 specific comments , 1 general comment so far) : https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/

AnssiK: that's already addressed

<fjh> https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/2731

<AnssiK> https://dvcs.w3.org/hg/dap/raw-rev/52acb4877e86: https://dvcs.w3.org/hg/dap/rev/52acb4877e86

<fjh> ACTION: fjh to update LC-2731 as completed [recorded in http://www.w3.org/2013/01/09-dap-minutes.html#action04]

<AnssiK> 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

<trackbot> 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

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0052.html (Anne)

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0059.html (detailed, Rick)

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0066.html - device namespace

<fjh> editing offer: 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

<dtran> 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

<fjh> josh_soref: one concern - if we have something with an API that is abstracted, what does it mean to have two implementations.

<fjh> josh_soref: clear for proximity but not in generic case

<fjh> ... fantasi publishes annual compendiums of CSS specs, likewise for WHATWG specs

<fjh> ... compendium is spec that is implemented

<fjh> josh_soref: still allows them to move forward

<fjh> need to be clear what is authoritative

AnssiK: i could easily hack that in
... we could easily product such a document out of what we have today

<dom> [that seems to be still orthogonal to fjh's question about design rather than packaging]

<dtran> 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

<dtran> 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

<fjh> to be concrete, is this the correct design discussion reference, 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

<AnssiK> we experimented with constructor in some early Battery Status API drafts, e.g.: 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

<fjh> 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

<Zakim> 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

<fjh> 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

<fjh> 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

<fjh> 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]

<trackbot> 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

<fjh> 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

<fjh> ACTION: fjh to contact Richt offline re network service discovery [recorded in http://www.w3.org/2013/01/09-dap-minutes.html#action06]

<trackbot> Created ACTION-610 - Contact Richt offline re network service discovery [on Frederick Hirsch - due 2013-01-16].

Magnetic Field Events

<fjh> https://wiki.mozilla.org/Magnetic_Field_Events

fjh: question of whether we should be doing this in this group
... anyone have any comment on it?

<bryan> 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

<AnssiK> +1 to start with UCs

fjh: next step is to determine what this is for

<fjh> I'll respond on the list asking for use cases

fjh: i'll respond on the list

Upcoming meetings

<fjh> 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

<dom> [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

<fjh> http://www.w3.org/2009/dap/track/actions/open

<fjh> http://www.w3.org/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

<bryan> there will be considerable discussion of media capture in that meeting

fjh: it's in the burlington area (?)
... Feb 5-7 (?)

<bryan> 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

<dom> Bedford

dom: it's Bedford, MA

<dom> hosted by ACME Packet

<fjh> Actions on Anssi to update specs, fjh to reply on list and ask for proposal from Rick, potential f2f hosts to check on hosting

<dom> Media Capture F2F during WebRTC/RTCWeb meetings

Adjourn

trackbot, end meeting

- DRAFT -

Device APIs Working Group Teleconference

09 Jan 2013

Attendees

Contents