Device APIs Working Group Teleconference

06 Feb 2013


See also: IRC log


Frederick_Hirsch, Anssi_Kostiainen, Rich_Tibbett, Dzung_Tran, Claes, Cathy_Chan, Laszlo_Gombos, Diana_Cheng, Giri_Mandyam, Claes_Nilsson, Clarke_Stevens
fjh, gmandyam


<trackbot> Date: 06 February 2013

<fjh> Scribenick: fjh

Welcome, agenda review, scribe selection, announcements

Media TF charter updated: http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0005.html

MediaStream Recording FPWD published http://www.w3.org/TR/2013/WD-mediastream-recording-20130205/

Minutes approval


RESOLUTION: Draft minutes from 23 January 2013 are approved.

<gmandyam> Scribenick: gmandyam

F2F Planning & Roadmap

<fjh> TPAC 2013: Nov 18-22 in Shenzhen - http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0095.html

<fjh> not planning on having F2F in April and not in May either, possible hosting in Germany in June

<fjh> ... but need to first make sure we have work that justifies having F2F. As far as I can tell, Web Intents/Web Activities would be main driver

<fjh> not sure we need it for Network Discovery

<fjh> richt: agree, list is working fine

<fjh> have been talking with Wonsuk about overlap of SysApps and DAP, need to make sure consistent

<fjh> ... e.g. common contacts data format, and consistency of APIs where possible

Contact and Calendar API's must be progressed beyond their current state before DAP can credibly liase with SysApps WG regarding commonalizing specs.

<fjh> so F2F planning is not clear, could meet in June, or Sept, if in Sept maybe not at TPAC etc

<fjh> please share thoughts with me if you have suggestions

Network Service DIscovery

<fjh> New draft out that incorporates all of the comments. Thanks to Cathy for summarizing the issues.

richt: A lot of feature requests in Cathy's summary. Good rationale for the requested features. We are tending for simplicity and minimum viable product.
... Managing uPnP devices is not a key use case for us. We are focused on bi-directional communication. Focus on uPnP distracts from other protocols.
... This work is set up for longevity.
... We may have to push requested features out of implementation.

The current spec has cleaned up uPnP items. What is left are feature requests.

Cathy: Need to review latest changes. May have additional comments. Will defer to group on feature requests. Agree with Rich that too much focus on uPnP may be a distraction.

<fjh> ACTION: fjh to review SysApps and DAP overlap and discuss with SysApps chairs [recorded in http://www.w3.org/2013/02/06-dap-minutes.html#action01]

<trackbot> Created ACTION-612 - Review SysApps and DAP overlap and discuss with SysApps chairs [on Frederick Hirsch - due 2013-02-13].

richt: Key barrier to implementation is user experience (for local networking). We should give some example user stories. Ultimate objective is to remove dialog boxes, by allowing sharing/discovery to happen by building on top of normal networking calls, using CORS.

<bryan> +1 to that idea to use CORS

<fjh> richt, can you please send note to list on this

bryan: Calls to CORS-enabled servers would have trusted devices. Device trust model is out-of-scope.
... This spec will enable the smart network environment.

richt: CORS doesn't have semantics yet for what is needed.

<richt> CORS lacks semantics to allow me to share my service with only 'localhost' or 'local network' for example. We may want to expand the semantics available to CORS.

<richt> This will allow us to build a system that does not rely on prompting but enforces the CORS from other devices in the current network.

<bryan> Leaving management of the set of allowed origins that CORS-enabled servers unspecified for now does not mean that this will go undone; other devices can offer management interfaces through which users configure the trusted origins. Having this API in DAP may drive further work on permissions managent for locally-network devices.


fjh: Attended privacy IG (PING). They reviewed Ambient Light & Proximity APIs. Most of the feedback is related to systemic issues, or broad issues. I will summarize conclusions and also draft a Note to provide general guidelines for DAP on privacy concerns than span specifications.

OMA Liaison, Device Apps Network Efficiency (DANE)

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

OMA DANE work does not have significant overlap with DAP. It is closer to SysApps WG, with policy and security work.

bryan: My involvement in OMA is mainly at board level. Didn't see the liason statement that went out. There has been discussion on API work.

<fjh> bryan: network information might be related

bryan: DANE is also looking a device bus with bi-directional communication.

<fjh> To summarize, metering, bandwidth discussions in DAP are possibly related

bryan: Network Info spec could feed into OMA. I've been telling OMA to use consistent techniques, which allows to expose OMA enablers as Web API's.

<fjh> ACTION: fjh to draft proposed OMA liaison response [recorded in http://www.w3.org/2013/02/06-dap-minutes.html#action02]

<trackbot> Created ACTION-613 - Draft proposed OMA liaison response [on Frederick Hirsch - due 2013-02-13].

Will draft a response; Bryan to add notes.

<fjh> Bryan sent email re OMA liaison http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0021.html

Battery API Testing

<fjh> Scribenick: fjh


gmandyam: shared slides regarding battery testing, also sent an email, to make sure issue is noted
... see slide 2, would like battery API
... would like to be able to use battery status to affect networking frequency etc
... described results at web performance workshop, goal to extend battery life when networking
... slide 3, believe we need to test battery API under stress (stress test)
... tried to match battery API with native meter, on PC did not see match under networking
... see slide 4
... used XAMPP, Apache wrapper

fjh: (see slides)

gmandyam: not claiming (yet) that this is a bug in firefox, but suggest we need a test for this sort of load test
... slide 5 gives some suggestions for next steps

fjh: conclusions - 1 stress test and see if battery API matches system battery meter
... 2. share code for this

anssik: current test suite exercises CPU to do prime calculations, thus a form of stress test, did not notice issues Giri has seen
... seem to be implementation bugs, suggest Giri report bug to Mozilla
... happy to merge additional stress tests if you contribute them

gmandyam: not enough to detect power level change, but need to check against reference

anssiK: each implementation will have own glue code, sometimes close to real time, sometimes not
... the version you are using might not have frequent updates

fjh: agree that Giri you may want to provide Mozilla test case and bug report

gmandyam: ok, I'll submit a bug report

Proximity and Ambient Light LC


fjh: update on status?

anssik: believe have handled at all last call comment
... design change will not be included

fjh: is window stuff all resolved

anssiK: yes, anne thought idea was interesting, doug suggesting keeping spec as it is

fjh: can you please send out message noting that not making a change here

anssik: will reply

Editorial Best Practices

fjh: Change in progress to offer more general ReSpec support
... much thanks to Anssi for ReSpec contributions, some documentation might help

Network Information API


fjh: we need to get this list discussion to reach a conclusion

bryan: my response to OMA may help with this

lgombos: have sent some ideas as well
... still have wide disagreements on list, to progress spec, need to set a deadline

fjh: +1 we need to progress this
... suggest we make a decision in two weeks

Web Intents and Web Activities

Web Intents removal from WebKit, https://lists.webkit.org/pipermail/webkit-dev/2013-January/023537.html

fjh: discussion, not decision?

lgombos: could keep code in webkit, but disable, will ask question on webkit mailing list, what we might expect to have to replace it, would prefer to disable and not remove it
... people prefer to remove dead code, but in this case it is not impacting other feature development

anssik: was the person suggesting removal the original author

lgombos: not sure

Web Activities update, https://wiki.mozilla.org/WebAPI/WebActivities

<richt> removal of web intents reinforces the fact the UI considerations for prompting are hard. I wonder if Web Activities addresses this better.

lgombos: probably did not want this shipping in production code. Is RIM/Blackberry shipping their implementation?

fjh: will check with Josh
... might be helpful to check with Mounir

Action Items


<trackbot> ACTION-474 -- Adrian Bateman to make a proposal for Network Information API -- due 2012-10-15 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/474


<trackbot> ACTION-565 -- Josh Soref to propose text for HTML Media Capture to allow for alternative capture device if specified device not available -- due 2012-08-22 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/565


<trackbot> ACTION-592 -- Niklas Widell to provide draft sensors landscape document -- due 2012-11-09 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/592

close ACTION-611

<trackbot> Closed ACTION-611 Look at automating generation of static docs out of respecs docs.

Other Business

No call next week, next call 20 Feb

RESOLUTION: Cancel call 17 April


Summary of Action Items

[NEW] ACTION: fjh to draft proposed OMA liaison response [recorded in http://www.w3.org/2013/02/06-dap-minutes.html#action02]
[NEW] ACTION: fjh to review SysApps and DAP overlap and discuss with SysApps chairs [recorded in http://www.w3.org/2013/02/06-dap-minutes.html#action01]
[End of minutes]

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