Device APIs Working Group Teleconference -- 06 Feb 2013

<trackbot> Date: 06 February 2013

Welcome, agenda review, scribe selection, announcements

<fjh> ScribeNick: fjh

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

http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/att-0087/minutes-2013-01-23.html

RESOLUTION: Draft minutes from 23 January 2013 are approved.

F2F Planning & Roadmap

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

<gmandyam> Scribenick: gmandyam

<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> fjh: not sure we need it for Network Discovery

<fjh> richt: agree, list is working fine

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

fjh - Moving on to Network Svc. Discovery

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

Network Service DIscovery

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

<fjh> s///

<fjh> s|s/member://||

richt: 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.

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

Privacy

fjh: Privacy topic to be added to agenda.

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

fjh: Attended privacy IG. They reviewed Ambient Light & Prox. fjh on the hook to summarize conclusions and provide guidelines for DAP on privacy.

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

OMA Liaison, Device Apps Network Efficiency (DANE)

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

fjh: 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> metering, bandwidth discussions in DAP are possibly

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

fjh: Will draft a response; Bryan to add notes.

Battery API Testing

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

<fjh> gmandyam: shared slides regarding battery testing, also sent an email, to make sure issue is noted

<fjh> ... see slide 2, would like battery API

<fjh> ... would like to be able to use battery status to affect networking frequency etc

<fjh> ... described results at web performance workshop, goal to extend battery life when networking

<fjh> ... slide 3, believe we need to test battery API under stress (stress test)

<fjh> ... tried to match battery API with native meter, on PC did not see match under networking

<fjh> ... see slide 4

<fjh> ... used XAMPP, Apache wrapper

<fjh> (see slides)

<fjh> ... not claiming (yet) that this is a bug in firefox, but suggest we need a test for this sort of load test

<fjh> ... slide 5 gives some suggestions for next steps

<fjh> ... conclusions - 1 stress test and see if battery API matches system battery meter

<fjh> ... 2. share code for this

<fjh> anssik: current test suite exercises CPU to do prime calculations, thus a form of stress test, did not notice issues Giri has seen

<fjh> ... seem to be implementation bugs, suggest Giri report bug to Mozilla

<fjh> ... happy to merge additional stress tests if you contribute them

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

<fjh> anssiK: each implementation will have own glue code, sometimes close to real time, sometimes not

<fjh> ... the version you are using might not have frequent updates

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

<fjh> gmandyam: ok, I'll submit a bug report

Proximity and Ambient Light LC

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

<fjh> fjh: update on status?

<fjh> anssik: believe have handled at all last call comment

<fjh> ... design change will not be included

<fjh> fjh: is window stuff all resolved

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

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

<fjh> anssik: will reply

Editorial Best Practices

<fjh> Change in progress to offer more general ReSpec support

<fjh> fjh: much thanks to Anssi for ReSpec contributions, some documentation might help

Network Information API

<fjh> https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html

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

<fjh> bryan: my response to OMA may help with this

<fjh> lgombos: have sent some ideas as well

<fjh> ... still have wide disagreements on list, to progress spec, need to set a deadline

<fjh> fjh: +1 we need to progress this

<fjh> fjh: suggest we make a decision in two weeks

Web Intents and Web Activities

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

<fjh> fjh: discussion, not decision?

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

<fjh> lgombos: people prefer to remove dead code, but in this case it is not impacting other feature development

<fjh> anssik: was the person suggesting removal the original author

<fjh> lgombos: not sure

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

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

<fjh> fjh: will check with Josh who is here

<fjh> fjh: might be helpful to check with Mounir

Action Items

<fjh> ACTION-474?

<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

<fjh> ACTION-565?

<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

<fjh> ACTION-592?

<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

<fjh> close ACTION-611

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

Other Business

<fjh> No call next week, next call 20 Feb

<fjh> RESOLUTION: Cancel call 17 April

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

- DRAFT -

Device APIs Working Group Teleconference

06 Feb 2013

Attendees

Contents