See also: IRC log
<trackbot> Date: 24 April 2013
<scribe> ScribeNick: fjh
Reminder, June F2F has been canceled, http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0035.html
Updated WD of Network Service Discovery has been published on 4 April, see http://www.w3.org/TR/2013/WD-discovery-api-20130404/
Media Capture TF update, http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0000.html
Welcome to new DAP participants, http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0016.html
No call next week on 1 May, next call is 8 May.
fjh: need to discuss status of WebIntents and Web Activities
... would like to see this work happening transparently on public list and in the group rather than in private
Approve minutes from 27 March 2013
http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/att-0034/minutes-2013-03-27.html
RESOLUTION: Minutes from 27 March 2013 are approved
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0013.html
fjh: CfC ended 23 April, with indications of explicit support, so we can go ahead with this
RESOLUTION: Move DAP tests to Git per http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0011.htm4
<scribe> ACTION: dom to move DAP tests to Git, with help from others as needed [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action01]
<trackbot> Created ACTION-625 - Move DAP tests to Git, with help from others as needed [on Dominique Hazaël-Massieux - due 2013-05-01].
fjh: two items to talk about, one is specific feedback on specific APIs and other is general considerations related to APIs
Constructor, http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0008.html
resolution - http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0028.html
anssik: non-issue, defined in DOM4 specification, and terminology is up to date
... asked anne if anything should be changed, no response, so this can be closed
<anssik> https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.html#terminology
<anssik> points to DOM4
<anssik> http://dom.spec.whatwg.org/#constructing-events
gmandyam: working on image capture specification, think you need at minimum of type of event, so Anne comment seems to be valid
anssik: how to construct an event is defined in DOM4
<gmandyam> Clarification: Based on my understanding of DOM4, the event has a mandatory constructor with a minimum arugment of DOMString type
<scribe> ACTION: anssik to update Proximity spec to clarify event constructor aspects [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action02]
<trackbot> Created ACTION-626 - Update Proximity spec to clarify event constructor aspects [on Anssi Kostiainen - due 2013-05-01].
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0009.html
resolution - http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0027.html
<anssik> https://dvcs.w3.org/hg/dap/diff/cf48e944bbad/light/Overview.src.html
anssik: fix completed
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0020.html
anssik: idea is to change API yet not break existing implementations
... replace exceptions and replace with return of boolean
... simplifies development
... sent a proposal, update to editors draft
fjh: does this apply to all APIs?
anssik: mozilla indicated that they can update implementation
fjh: to repeat what I heard, this simplifies error handling for async call, so if immediate error return false rather than using exceptions
anssik: correct
fjh: can we apply to other APIs
anssik: in DAP no other APIs use this mechanism
fjh: this should be documented for a general API design document so that we are consistent across W3C working groups, as one of the practices to follow
... need to follow up where the general API design is documented
anssik: anne has good ideas regarding APIs
<gmandyam> +q
fjh: we need this documented somewhere other than anne's head
... believe it was Robin's document
<anssik> http://darobin.github.io/api-design-cookbook/#exceptions
anssiK: cookbook
<scribe> ACTION: fjh to contact Robin about returning booleans versus exceptions for cookbook update [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action03]
<trackbot> Created ACTION-627 - Contact Robin about returning booleans versus exceptions for cookbook update [on Frederick Hirsch - due 2013-05-01].
gmandyam: re image capture, exceptions can be raised if synchronously detected
... need to handle async differently
fjh: anssi this change is in place, what next
anssik: shared change on list, got feedback, made update, received more suggestions from Anne
<scribe> ACTION: anssik to send email to list with final proposal to update the "processing vibration patterns" algorithm to return boolean instead of throwing [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action04]
<trackbot> Created ACTION-628 - Send email to list with final proposal to update the "processing vibration patterns" algorithm to return boolean instead of throwing [on Anssi Kostiainen - due 2013-05-01].
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0052.html
<anssik> s/tackle/address/
anssik: feedback off list that this is fine, with change of 'tackle' to 'address', will update specification soon
<anssik> got some LGTM responses off-the-list re intro update
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0019.html
proposed resolution - http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0043.html
anssiK: anne reviewed light and proposed we merge the two interfaces, for different granularity
... one lux value , one string dim
fjh: these were to address two different use cases, right?
anssik: anne suggested that both be exposed on same interface, with one handler
... support this change
... only concern is that if interested in state only, will get extra events if lux value changes
fjh: is it really good to get extra events?
... need to see if we have consensus
... we need to distinguish handling use cases simply versus implementation detail, how important and different are the use cases?
... wonder if we really need the lux value at all, isn't the higher level approach enough (dim etc)
... can ask this on the list
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0025.html
fjh: this comment reflects discussion about the DAP APIs on a different list, about issues that we resolved earlier, apparently expressing concern whether we are doing the right thing across APIs
... it might warrant another look
... but we should not be reopening closed issues without new information
... idea related to single sensor spec
... we have made the decision we did to enable faster development, independent tracks and testing and simplicity
anssik: work is on an alternative proposal, should not block until we see an alternative specification
fjh: consensus on call is to continue with current work until new information such as an alternative proposal is presented
prefix issue , http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0054.html (Jean-Claude)
fjh: await comment from Richt
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0045.html
http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0046.html
fjh: looks like nothing needs to be done here, please comment on list if something needs to be done
anssik: have additional discussion point. Talking to Mounir who talked with developers
... desire to expose latency as well as bandwidth
fjh: who will make proposal?
anssik: i do not have time for this
fjh: if anyone can help, please volunteer on list
gmandyam: concern from developers on how well bandwidth is estimated, similar issue expected with latency
... won't be useful unless commonality on how it is estimated
<scribe> ACTION: fjh to ask about latency and estimation mechanism for network information on DAP list [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action05]
<trackbot> Created ACTION-629 - Ask about latency and estimation mechanism for network information on DAP list [on Frederick Hirsch - due 2013-05-01].
http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0036.html
fjh: highlighting this in case
you missed it
... not clear that we should do this first
... thoughts and comments welcome on list
... see that it offers benefits in terms of composition etc we
may consider for future work - what are testing implications or
implementation support
anssik: do not want to change existing specs
fjh: that is one of the questions
gmandyam: too much risk
fjh: saw pushback discussion in media capture TF
gmandyam: SysApps is adopting
this, some discussion at F2F, decided not applicable in sync
interfaces
... do not seem to be uniformly applied
anssik: will look into it
fjh: what I am hearing is that we should defer this to new work unless convinced otherwise
gmandyam: need to consider how ubiquitous support for this is, not sure WebKit support is being used.
fjh: need to have new visibility
and transparency into discussions
... anyone aware of anything new?
silence
11-15 November is TPAC, in Shenzhen, China.
fjh: Should DAP plan to meet in
China at TPAC?
... too few on this call to decide
... once consideration is possible joint meeting with
SysApps
gmandyam: was suggested at SysApps F2F, perhaps 1/2 day to discuss areas of overlaps
fjh: it comes down to whether DAP will have enough work to justify a F2F
gmandyam: lots could change in six months, but currently do not see items to justify F2F, personally
fjh: understood
ACTION-446?
<trackbot> ACTION-446 -- Frederick Hirsch to review security issue http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html -- due 2011-08-24 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/446
fjh: this may be moot
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
anssik: still working on this
ACTION-591?
<trackbot> ACTION-591 -- Greg Billock to work with Mounir and James to create new webintents draft that reflects web activities and issues -- due 2013-03-29 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/591
fjh: we need an update on this
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
ACTION-622?
<trackbot> ACTION-622 -- Frederick Hirsch to follow up on concrete actions based on PING input -- due 2013-03-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/622
ACTION-624?
<trackbot> ACTION-624 -- Richard Tibbett to prepare WD of Network Service Discovery for publication, including link and validity checks -- due 2013-03-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/624
ACTION-624: Updated WD of Network Service Discovery has been published on 4 April, see http://www.w3.org/TR/2013/WD-discovery-api-20130404/
<trackbot> Notes added to ACTION-624 Prepare WD of Network Service Discovery for publication, including link and validity checks.
close ACTION-624
<trackbot> Closed ACTION-624 Prepare WD of Network Service Discovery for publication, including link and validity checks.
fjh: close pending items
close ACTION-474
<trackbot> Closed ACTION-474 Make a proposal for Network Information API.
close ACTION-623
<trackbot> Closed ACTION-623 Prepare transition request for HTML Media Capture.
issue-127?
<trackbot> ISSUE-127 -- Status section of Battery CR draft should include exit criteria and at-risk items -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/127
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
None
No call next week on 1 May, next call is 8 May.