W3C

Device APIs Working Group Teleconference

24 Apr 2013

Agenda

See also: IRC log

Attendees

Present
Frederick, Hirsch, Giri_Mandyam, Bin_Hu, Anssi_Kostiainen, Clarke_Stevens
Regrets
Chair
Frederick Hirsch
Scribe
fjh

Contents


<trackbot> Date: 24 April 2013

<scribe> ScribeNick: fjh

Welcome, agenda review, scribe selection, announcements

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

Minutes approval

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

CfC to move tests to Git

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

APIs

fjh: two items to talk about, one is specific feedback on specific APIs and other is general considerations related to APIs

Proximity Constructor

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

Proximity - Unrestricted double

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

Vibration - Throw and Pause

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

Vibration - Introduction clarification

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

Proximity & Light - two events

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

Proximity & Light - Overall API comment

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

Network Service Discovery

prefix issue , http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0054.html (Jean-Claude)

fjh: await comment from Richt

Network Information API Comments

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

DOM Futures

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.

WebIntents

fjh: need to have new visibility and transparency into discussions
... anyone aware of anything new?

silence

TPAC & F2F Planning

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 item review

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 review

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

Other Business

None

No call next week on 1 May, next call is 8 May.

Adjourn

Summary of Action Items

[NEW] 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]
[NEW] ACTION: anssik to update Proximity spec to clarify event constructor aspects [recorded in http://www.w3.org/2013/04/24-dap-minutes.html#action02]
[NEW] 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]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $