See also: IRC log
<trackbot> Date: 06 February 2013
<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/
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.
<gmandyam> Scribenick: gmandyam
<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
<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.
<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
<fjh> Scribenick: fjh
http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0002.html
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
http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0094.html
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
fjh: Change in progress to offer more general ReSpec support
... much thanks to Anssi for ReSpec contributions, some documentation might help
https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html
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 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-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
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
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
close ACTION-611
<trackbot> Closed ACTION-611 Look at automating generation of static docs out of respecs docs.
No call next week, next call 20 Feb
RESOLUTION: Cancel call 17 April