# Device APIs Working Group Teleconference







## 01 Nov 2012







[Agenda][3]







See also: [IRC log][4]







## Attendees







Present







    Adrian_Bateman, Anssi_Kostiainen, Bryan_Sullivan, Cathy_Chan,



Claes_Nilsson, Dominique_Hazael-Massieux, Donyun_Kim, Doug_Schepers_(shepazu),



Eduardo_Fullea, Frederick_Hirsch, Geun-Hyung_Kim_(comus), Giri_Mandyam,



GregBillock, Harald_Alvestrand, Hiroyuki_Aizu, Jean-Claude_Dufourd,



Jinhong_Yong, Jonas_Sicking, Jonathan_Jeon, JongSoo_Oh, Josh_Soref,



Jungkee_Song, Kensaku_Komatsu, Milan_Patel, Mounir_Lamouri, Naoyuki_Sato,



Niklas_Widell, Noriya_Sakamoto, Rich_Tibbett, Sakari_Poussa, Salon_pasteur,



Shin-Gak_Kang, Soonbo_Han, Sung_Hei_Kim, Suresh_Chitturi, Sylvain_Lalande,



Travis_Leithead, Wonsuk_Lee, Wook_Hyun, Yoshiharu_Dewa, Yuan_Ji, giuseppe,



jerome_giraud, Nick_Doty, Hidetoshi_Yokota, Olivier_Thereaux, Youenn_Fablet,



Soonhong_Daniel_Park







Regrets











Chair







    Frederick_Hirsch







Scribe







    timeless, richt







## Contents







  * [Topics][5]







    1. [Administrative][6]







    2. [Agenda Review][7]







    3. [Minutes approval][8]







    4. [Relationships with SysApps WG][9]







    5. [battery api][10]







    6. [Vibration API][11]







    7. [HTML Media Capture][12]







    8. [Vibration][13]







    9. [Proximity and Ambient Light Sensors][14]







    10. [Network Information API][15]







    11. [Network Information][16]







    12. [Web Intents/Web Activities][17]







    13. [Web Activities][18]







    14. [Agenda review][19]







  * [Summary of Action Items][20]







* * *







<trackbot> Date: 01 November 2012







### Administrative







<dom> trackbot, start meeting







<trackbot> Meeting: Device APIs Working Group F2F







<trackbot> Date: 01 November 2012







<dom> scribenick: bryan







fjh: welcome and logistics







... intros







<fjh> hi I'm chairing, from Nokia, Frederick Hirsch







anssik: from nokia, editing a bunch of specs, been out for a while and will



catch up







bryan: from AT&T, not editing







jcdufourd:







dom: Dominique Hazael-Massieux, w3







Eduardo: from Telefonica







Jungkee: editing Pick Media etc







Claes: Claes Nilsson from Sony, editing







<jgiraud> jerome giraud: orange







(missing most of them...)







noriya: Toshiba







sato: Sato, Sony







kensaku: Kensaku Komatsu from NTT communications







Yoshiharu_Dewa: Yoshiharu Dewa, Sony also from Sony







<shan> Soonbo Han, LGE







shan: Soonbo Han from LG, interested in Web Intents







jsoh: also from LG







... JongSoo_Oh, LGE







dnkim: also from LG







Hidetoshi: Hidetoshi Yokota from KDDI







giuseppe: Giuseppe Pascale from Opera







Harald_Alvestrand: Harald Alvestrand, Google, WebRTC chair, observer







daniel_samsung: Soonhong Daniel Park, Samsung







dnkim: Donyun Kim, LG Electronics







skim: Sung Hei Kim from ETRI







... Sung Hei Kim from ETRI







wook_hyun: also from ETRI







<comus> <geunhyung> geunhyung from Mobile Web Forum







<gmandyam> Giri Mandyam, from Qualcomm Innovation Center







shingak_kang: from (.. Korea)







gmandyam: from QiC, member







Jungkee: Jungkee Song, Samsung Electronics, working on Pick-*-Intent in the



group







<nwidell> nwidell, Niklas Widell, from Ericsson AB







nwidell: Niklas Widell, from Ericsson







youenn: Youenn Fablet, observer, interested in Web Intent and service



discovery







Milan_Patel: Milan Patel, Huawei







(missed the gentlemen before and after Niklas)







(observers)







<mounir> mounir, Mozilla







fjh: next topic is to walk through agenda







### Agenda Review







fjh: goal is to advance the specs, these first are in good shape







<dom> [DAP WG home page][21]







fjh: battery spec is in cr, when to goto rec and get testing started is the



question







... ambient light and proximity seem stable, the question is whether we can



get to last call







... vibration is in cr, need to assess test case status and when we can



progress it







... in summary to figure out roadmap for specs in good shape







... may also talk about network info api (maybe shelved)







... also privacy in general, in principle, christine sharing the privacy group



may join us







... we kind of pushed the earlier work aside and focused on data minimization,



but need to consider revisiting







... we may take longer breaks for discussions







... after break html media capture, in LC and stable but has some comments



recently







... we got lc comments, and some responses were not accepted. we need to



resolve all today to proceed to LC







... after lunch, web intents all afternoon







... need to review webapps discussion, and discuss status and implementations,



issues etc from google







... mounir also is here and we need to take these two pieces of work forward







... tomorrow we will start at nine







... tomorrow on the specs built upon web intents, including calendar to get it



moving again







... then claes's work on web intents addendum. cathy is not here (Hurrican



Sandy) but we need to discuss the comments







claes: there were breakout sessions and will share results







fjh: after lunch richt's network service discovery draft







... somewhere about media capture and streams







... hopefully travis will be here to talk about tracks







... then something about billboards, (digital signage)







... maybe talking about coremob what to do with them







... on interop, a lot of work being done on testing and tools







... been working on the actions and not much to do there







... rough outline so far, anything else?







### Minutes approval







fjh: any objection to approving the minutes







<fjh> [http://lists.w3.org/Archives/Public/public-device-



apis/2012Oct/att-0014/minutes-2012-10-03.html][22]







proposed RESOLUTION: Minutes from 3 October 2012 are approved.







**RESOLUTION: Minutes from 3 October 2012 are approved.**







bryan: what about sysapps







... would like to talk about synergy







### Relationships with SysApps WG







<fjh> I can scribe for this topic Bryan







bryan: would like to have synergy with DAP, and share common privacy



approaches for example







... would like to look at privacy more closely







dom: how can we be concrete on this







bryan: might consider extending existing DAP interfaces in sysapps







richt: if it can run in the browser context it should be defined in DAP







<fjh> overlap of dap and sysapps is about five people







<fjh> at least hands raised in the room







<dom> [Overlap of formal participants between DAP and SysApps WG][23]







jcdofourd: some apis picked up in sysapps have been shelved in this group, it



should not be forbidden in another







fjh: we need to be productive, and ensure that browser context use is in the



specs that browser vendors will implement







... maybe it would make sense to see how it plays out, but not get into it



deep now







jcdofourd: execution and security model is a worse overlap, a meta-level for



interfaces







... how things should work around security







fjh: in other words we should look at it







... there was a contribution in sysapps







jcdufourd: Jean-Claude Dufourd (there are some proposals)







<fjh> ISSUE: should DAP review and take advantage of SysApps security models







<trackbot> Created ISSUE-126 - Should DAP review and take advantage of SysApps



security models ; please complete additional details at



[http://www.w3.org/2009/dap/track/issues/126/edit][24] .







fjh: concerned about two working groups with different IPR etc not sure what



we can do here







nwidell: when the charter was discussed, the sysapps APIs were intended to



have a flexible security model







<dom> [SysApps WG charter][25]







### battery api







anssik: ... brief overview of battery status api







... various features exposed for implementation in browsers and web-based



os's... works in both world







... sitting in cr for a while. no CRs since then, so the spec is considered



stable







... currently a stable version in firefox nightly







... backends are available for windows







<dom> [Battery API test suite][26]







anssik: been working on a test suite, just run the suite and provide feedback







... it's a bit tricky since automated tests are not possible or easy







... part of the tests address interfaces and others are manual tests







... results are manually validated







... next steps after validation of the suites, moving to PR







richt: we don't have to rush to PR







... what were the implementations so far?







anssi: firefox (browser and OS), tizen 2.0







<dom> [Implementation status of battery API][27]







richt: has this seen any adoption and interesting use cases?







anssik: developers seem excited at conferences







... when you combine this with some other APIs more cool stuff is expected







<AnssiK> * spec in CR since May 2012: [http://dvcs.w3.org/hg/dap/raw-



file/tip/battery/Overview.html][28]







<AnssiK> * no normative changes since CR, spec changelog:



[http://dvcs.w3.org/hg/dap/log/tip/battery/Overview.html][29]







fjh: we need to ensure its done right and do not want to rush, but move



forward







<AnssiK> * implementation status: Firefox (Nightly), Firefox OS, some WebKit



ports (such as EFLWebKit):



[http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API][27]







richt: the objective is lots of implementations, not just a spec







<AnssiK> * try it on Firefox Nightly (will ship in Firefox 18 unprefixed?):



[http://nightly.mozilla.org/][30]







<AnssiK> * test suite, reviews appreciated: [http://w3c-



test.org/dap/battery/tests/submissions/anssik/][31]







<AnssiK> * battery-interface.html is the only fully automated test, others are



functional tests







richt: we have hints that clarifications may be needed, maybe leave in CR for



a couple or years as we work them out







<AnssiK> * next: move to PR?







<Zakim> dom, you wanted to ask about (other) implementation plans, idlharness



and to ask about testing methodology in DAP general







fjh: not sure that is a good idea







<AnssiK> [that was an outline of my talk]







dom: so to recap, just mozilla as a browser today. not sure we should move to



PR with just one browser implementing







... any comments from the room?







<fjh> i agree with Dom, but some work that doesn't progress stays indefinitely



in CR we do not want to end up in that state.







mounir: its in firefox 16







anssik: will try to provide a live demo







richt: at a design level, its good and on the roadmap with other sensors,



competing with other work







... we agree with the approach and the design though







dom: any other implementation plans to share







yungkee: implementation in tizen is complete







fjh: answer is firefox and tizen implementations so far







dom: tizen is not a browser







anssik: firefox OS and browser are different too







dom: important to stick to browsers as the goal for implementations







anssik: how much platform-specific code is in tizen?







jungkee: will follow up to see what can be shared







wonsuk: -> [https://developer.blackberry.com/html5/apis/blackberry.system.html



#.event:batterystatus][32] "BlackBerry 10" implementation







anssik: (shows a demo of tests)







... just looking at the interface as specified, easy stuff







... (runs a discharging tests) the test calculates primes, shows that the



battery is being eaten up by both CPU cores being used for the calculation







... calculation is in the web worker, waiting for the discharging time to



update... this shows how testing this type of API can be challenging







... maybe webdriver could help, so to emulate some operations







... the test was passed







... after running you have to validate by checking the system battery against



what was reported







... if the test fails, how to prompt the user needs to be figured out. for now



there appears to be a bug in the implementation







... deciding when to prompt the user is tricky







richt: probably should not mark as passed







anssik: got the language from the css reftests, to prompt the user on what is



expected







richt: in css tests you have visual feedback and also programmatic checking







dom: not sure the harness has this yet, but in this case it's a pass but check



result







... someone needs to bring the idea to the public testing list







anssik: so the harness API does not support







dom: not sure







... one of the difficulties is testing the API itself and also how it is



developed in an implementation







jungkee: haven't tried this test yet (richt asked)







giri: these are assert tests







gmandyam: until you have fully charged the battery you can't verify the



implementation







<richt> AnssiK: re: my question to Jungkee. Tests are very new (1 day old) so



they have not been run against the Tizen impl yet.







fjh: what I heard is that the test that matters are fully charging and



discharging?







gmandyam: time to discharge test requires a full discharge to verify







anssik: what you cant do in automated tests is determine if the reported value



is the actual value







... you have to check with other data e.g. at the OS level







gmandyam: have compared whats in the OS vs what's in javascript, and found



differences... should we consider that in the tests?







<richt> is that difference a rounding error gmandyam, or something more



serious?







anssik: it's up to the glue layer to define any translations exposed to the



browser







gmandyam: can we really say an implementation is compliant, it the reading



varies from the OS?







richt: is this a rounding error or a bigger difference?







gmandyam: it was pretty significant, almost a latency of the javascript, when



a significant change occured at the OS vs when it showed up in the javascript







<Zakim> dom, you wanted to mention idlharnes







mounir: we use the exact value that the OS tells you (thru the API), to avoid



fingerprinting we take steps







dom: there is a test harness for webidl, which will run most of those types of



tests automatically. we should use that as it can save work for those type of



tests







<mounir> mounir: our implementation only use OS APIs and try to comptue values



if there is no such APIs so you shouldn't see difference except rounding



values because we try to round to prevent too much fingerprinting (0.1234567



=> 0.12)







dom: also how much linking test cases with assertions so far?







anssik: about 90%







... looking at the spec (highlighting how paragraphs map to tests), its not so



easy to separate tests back to prose







dom: and thanks for getting these tests done







<mounir> ack







anssik: it's been good to work with mounir, a good collaboration







mounir: to report the issues we have found







... it's hard to test this in hardware, so we are using emulators







... so we change the value in the emulator and verify the change thru the API







... every platform has different implementations, we have found bugs in



different OS







... it's not as easy to check any version to see if it's conforming







Josh_Soref: one of the goals was to disclose when the device is about to run



out of battery, so the app can take action







... some divergence is acceptable between the system and user perception







... that this is different from some other estimate that is questionable is



not a valid concern







richt: a lot of what we say here for battery will apply to the other APIs, so



maybe we can move quicker based upon this discussion







... so I can test if the feature is supported thru the API?







mounir: (responds)







<mounir> mounir: the spec defines default values







mounir: we return those default values if we don't have the backend



implemented for the platform







anssik: if you expose the object but don't have the implementation, we test



for that, to avoid fingerprinting via a dummy interface







<fjh> ack







<AnssiK> this test is for devices that expose the BatteryManager interface,



but lack a backend implementation: [http://w3c-



test.org/dap/battery/tests/submissions/anssik/battery-created.html][33]







gmandyam: based upon the mobile perspective, we're trying to get developers



aware of battery state







... the level is clearly an estimate, but consistency with the OS is important







<AnssiK> as well as this one: [http://w3c-



test.org/dap/battery/tests/submissions/anssik/battery-interface.html][34]







gmandyam: I tested the mozilla implementation as input to a paper for the web



performance workshop next week







... when I discharged the battery all the way, there was a clear discrepancy



in the javascript (20-30%)







<AnssiK> [the first test is useful *only* if there's no backend impl]







Josh_Soref: that's the type of bug we need to see reported (it's ok, for the



UA battery report to indicate dying sooner, but not ok to report dying after



the OS)







<mounir> gmandyam: on which platform?







fjh: so next steps with this work







anssik: will continue on the tests, will test tizen devices when available



(also firefox OS, please provide one!)







... about the next process step







richt: before we have finished specs, and shelved with no implementations. we



should expect some inertia now, and some time before wider implementations







... its not a huge concern to get to PR, but we cant progress at this point



though the spec is still alive







anssik: IP committments kick in in REC so we need to get there asap







dom: until we get another browser implementation the question is pretty moot







<fjh> **ACTION:** dom to review Battery test and contribute more tests



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action01][35]]







<trackbot> Created ACTION-585 - Review Battery test and contribute more tests



[on Dominique Hazaël-Massieux - due 2012-11-08].







anssik: would be better if someone else also contributes tests







richt: lack of implementation does not imply disagreement (want to make that



key point)







dom: we have made a call for implementations, otherwise the spec is ready







richt: there doesn't seem to be disagreement, just not clear and broad



agreement







dom: one open question, what is the process for approving test suites







... by default, by review, etc







... the default is that they are approved until problems are found







richt: think we should have a code review







... W3C should have such systems in place







<fjh> **ACTION:** richt to review Battery tests [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action02][36]]







<trackbot> Created ACTION-586 - Review Battery tests [on Richard Tibbett - due



2012-11-08].







### Vibration API







anssik: spec is in CR since May







... minor clarifications, implemented in firefox OS, tizen. test suite draft



by robin







mounir: also firefox android







<AnssiK> * spec in CR since May 2012:



[http://dev.w3.org/2009/dap/vibration/][37]







<AnssiK> * minor clarifications since CR, changelog:



[http://dev.w3.org/cvsweb/2009/dap/vibration/Overview.html][38]







anssik: its exposed to the browser but if it doesn't have the hardware it



won't do anything







<AnssiK> * implementation status: Firefox, Firefox for Android, Firefox OS,



WebKit:



[http://www.w3.org/2009/dap/wiki/ImplementationStatus#Vibration_API][39]







<AnssiK> * test suite draft by darobin: [http://w3c-



test.org/dap/tests/vibration/submissions/robin/][40]







<AnssiK> * test suite TODOs: [http://w3c-



test.org/dap/tests/vibration/submissions/robin/TODO.txt][41]







<AnssiK> * next: work on the test suite







wonsuk: clarifying, wekbit supports many browsers based upon linux (a lot of



ports)







... the EFL port has many browsers in testing. this may be helpful to CR?







... (this was related to the battery API, not Vibration)







... Tizen is a Web-based OS, but provides different context (system app and



browser)







... we can provide test results based upon tizen for our target devices. will



that be helpful to move to CR for the battery API?







fjh: will the open-source status of the browser should help (this is the



question)







dom: is it a shipping browser that has battery, or an experiment







wonsuk: its testable in a test environment based upon the EFL port







dom: what we want is real browsers that are shipping to leave CR







richt: 2 is the minimum







<fjh> bryan: does browser implementation mean installable on any platform?







<fjh> timeless: apis for general web apps for general browsers in general



deployments







<fjh> timeless: test implementation not suitable for exiting CR







timeless: the browser needs to be a major browser, not puppet implementations







<fjh> need to clarify in battery API status that exit criterial for CR is 2



independent real world browsers







dom: technically we need to have two implementations, two real-world



implementations independently sourced







<fjh> ISSUE: status section of Battery CR draft should include exit criteria



and at-risk items







<trackbot> Created ISSUE-127 - Status section of Battery CR draft should



include exit criteria and at-risk items ; please complete additional details



at [http://www.w3.org/2009/dap/track/issues/127/edit][42] .







bryan: we are expecting real world implementations expected for wide use, not



just the "big five"







<GregBillock> re: battery implementation in webkit, see



[https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/battery][43]







<GregBillock> (I don't see it is enabled by any webkit-based browser



currently.)







dom: we need an exit criteria (not necessarily well-defined), and the director



will make a decision whether we have really met the criteria







### HTML Media Capture







fjh: we have a LCWD with some feedback







<fjh> general comment on HTML Media Capture comment



[http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/0050.html][44]







shepazu is here







fjh: thought about comments of doug







... e.g. might want mic vs video, different use cases







... other comments about front vs back and selection







... other work in getUserMedia supports streams and tracks etc... this seems



related to the goals







... maybe that's the solution, and it shouldn't be in html media capture







bryan: +1 to reuse







fjh: mime types dont seem to relate to the track objectives etc... what



problems are we trying to solve?







shepazu: comments are more about setting correct usability and privacy



expectations







... e.g. get camcorder. does that necessarily include audio, is video



recording automatically include audio?







anssik: think that users will expect what the native platform would provde







... that is an implementation concern







dom: to be clear, the html media capture is a shortcut to enable recording







... giving direct access to the native application through a button for



example







... the user doesn't have to 1st record and then upload. but it still uses the



basic OS framework, and nothing extra







... the media camera API will provide that







fjh: we need an intro section setting expectations







shepazu: the rewrite should address the relationship with getusermedia







fjh: agree we have a spec that is unclear per the landscape







shepazu: need to clarify that "camcorder" includes audio. that needs to be



clear.







dom: again camcorder only starts the native application







shepazu: in that case the author needs to know if they will get audio







fjh: I propose we update the abstract and introduction to clarify the purpose



and limitations of the spec, relationship to getusermedia etc and this should



help address the concerns







... clarify as Dom mentioned that is shortcut for file upload







dom: the application just hands the user to the native feature







<shepazu> [http://www.w3.org/2012/09/26-audio-minutes.html#item05][45]







dom: normal operations result and when coming back to the app, the user will



find the file and then upload etc







shepazu: upload what, does it include audio?







dom: if you need more control from the app, you need to use getusermedia







<shepazu> [WG concerns with HTML Media Capture API][46]







olivier: there are different perspectives on what features are involved here,



but it doesn't sound future proof







... we are talking about images, audio, and video, not just what devices give



you those







... from the audio WG we are worried that there are two APIs providing the



same things







anssik: we do need to clarify the keywords







... e.g. capture is "still image capture device"







... and camcorder is a "motion capture device"







shepazu: is this the wording or the keywords that are proposed to be changed?







... motion capture can be haptic etc, would suggest to use "video"







fjh: how real an issue is "camcorder" vs video?







olivier: the concern is more about consistency







shepazu: camcorder is an old term







Josh_Soref: (proposes an experiment)







richt: i am a web developer with lot of tools, this is about getting a file of



the type that comes from the camcorder, or the camera, or scanner etc







... more generally, we have a "accept" attribute that enables selection of the



type of file to get







... what ends up is a launch with filtering of the selected tools







... it's fine the way it is







shepazu: agree that there is a place for this, it addresses use cases



getusermedia does not







... we need more explanation of how HTML is being extended, and that



expectations for the author and user are not being clarified







... don't want the author to guess what the app will offer to the user







fjh: we got a comment that we need more clear text







anssik: we do need to more clearly describe how the options address the



different use cases







shepazu: that would help, for that part of it







fjh: so there is not enough info for a first time reader to understand, and we



need to improve that







dom: doug had another point, not just the link with HTML, but that he needs



more info about what is exposed to the user through the UI







fjh: we need to say something related to the content in the file (audio vs



video)







richt: offloading to a native app, we often can't tell the native app what we



expect. it's not a feature of the native app to allow that control







... you get just the ability to select a file type







shepazu: it's not just the file. you are interacting with the application,



e.g. a video camera, not a file type







dom: we are not getting a camera, but the file object







... what does is saying is that informative language update may not be enough







<Josh_Soref> [file picker with scanner][47]







dom: once you have the file, the app may be able guide the user to do



something different as needed by the app







<Zakim> Josh_Soref, you wanted to say that the option thing is silly since,



ideally the UA will just do this automatically







dom: if the app needs more control, then it needs to use getusermedia







Josh_Soref: dropped in picture links







<Josh_Soref> [file picker with camera][48]







Josh_Soref: want to note that people used to think of windows explorer as a



file picker







... this is now false, the picker can show other things as virtual files e.g.



a scanner







... the picker can offering ways to get data of a source, that could include



hints to the user







... the user can select different sources of the same type, e.g. an image or a



camera







... but in the end it's just a file that is being selected. if more is needed



the app should use getusermedia







gmandyam: a broader perspective, prior to joining the DAP WG, ...







... I heard two arguments in favor of html media capture







... the first is a bogus argument, don't see the value in adding a new DOM



element just for capture







... also the argument over the privacy approach is bogus







... even though getusermedia is still being developed, we can expect that a



dialog box will provide the user with options also







... in the next few months we will have similar and better capabilities with



getusermedia







dom: responding, was at the mediacapture TF meeting, and it is optimistic that



in 6 mos we will have a stable spec







<Josh_Soref> Josh_Soref: +1 (i minuted)







dom: there are also may use cases that dont need control of the camera, just



need a file e.g. picture that can be acted upon







... a simple declarative way to get a picture without dependency upon detailed



features







<fjh> +1 to having simple interface for functionality in addition to



getusermedia that offers more control







dom: coremob also has identified the use cases of getting a picture as



important







gmandyam: expect javascript libraries to extract away the complexity for those



apps that need just a simple picture capture







dom: agree libraries can also get the same output, but the library can't



expose things equivalent to the default UI of the device







richt: the way to look at this, with the file input type, that you get a file



picker. all the spec does is enable innovation at the file picker level







... this is not about control over the file, just selection







... making it easier for the users to get to the file (type) they want to



share







<fjh> "a quicker picker"







richt: purely innovation at the file picker level







anssik: love getusermedia, great for its use cases







... note that form based file upload was in HTML 2 in 1995, well tested over



the last 17 years. the UI is a non-issue







... additional point for doug, about privacy/security. if an app wants audio +



video, but I don't want audio just the video, ...







... i need the freedom to get the video without the audio







shepazu: you should be able to express what you want, and the user should be



able to modify that







... saying accept to one file type, doesn't necessarily imply both types of



content are acceptable







... want the user to know what the app's expectation is, and to give the user



the option to choose







dom: html can be used to express to the user what the app expects, before they



click the button







<gmandyam> Has anyone effectively rebutted the arguments in the HTML5 Rocks



article on gUM vs. HTML Media Capture? See



[http://www.html5rocks.com/en/tutorials/getusermedia/intro/][49]







richt: understand the intent, that user opt-in to audio is important







... that's not a feature of the native application, to offer that control by



an API of the platform







shepazu: when you popup the dialog, you chrome can't popup something that



clarifies what is asked for?







Josh_Soref: the popup will be the native recorder, and the only browser



interface is to run the native app, and to receive the output file







shepazu: you can ask it, whether it listens is another matter







olivier: at the moment you can, but specifying it is a start and will promote



development of the native APIs







<Zakim> shepazu, you wanted to support the use cases for this spec







shepazu: those who are developing platforms are in control, and can develop



this. we just need to make it possible thru the spec







... the audio WG wants the html media capture spec, to get to market quickly.







... getusermedia will take longer, and in the meantime this is critically



important







... really support the spec, but want it to be done right







dom: the only thing not possible is to enable recording of video only?







... to separate the video and audio?







... what is the use case, when would you want that?







shepazu: if you want videos, but have privacy concern about the collection of



an audio track







richt: we could put that in the dialog, and hand off to the native app, have a



File returned, then strip the audio out, and return the modified File to the



calling web page







<npdoty> there are some legal jurisdictions where recording audio requires a



higher legal bar than capturing video, fwiw







shepazu: not asking for that, just to inform the user







fjh: would it help to have keywords to allow the separate source types to be



included







shepazu: more keywords seems more complex... my solution is to have a list of



what is requested







fjh: so what olivier is requesting is that we think ahead







<Josh_Soref> [BlackBerry File Picker with Camera][50]







gmandyam: a question, if we think a separate file picker should be provided



for this API, for devices that have file pickers already, what are we



providing beyond the UI of the native app which the user might already be



comfortable with?







richt: if i want to upload a profile photo, today I pick a file through the



browser, or I exit the browser record a picture go back etc... this shortcuts



that loop







gmandyam: enabling a user experience not possible today is fine, but that



somewhat contradicts the assertion that the user only needs to work with the



native UI







richt: getusermedia is about staying in the browser and getting the media







... this otoh is about switching to the native app seamlessly







... they are different use cases and both needed. there is no choice between



these, they are both important







<Wonsuk> +1 for richt







fjh: suggest we get to the LC concerns and address them well







<AnssiK> LC comments: [https://www.w3.org/2006/02/lc-comments-tracker/43696



/WD-html-media-capture-20120712/doc/][51]







fjh: it would be useful to look at the LC comments each to see if something



has been missed, or is it this one issue?







Josh_Soref: doug wants to specify what is requested







... (showing the blackberry UI)







... we can already map the accept list to this type of dialog







fjh: can you do the camcorder case without audio?







Josh_Soref: probably not today







... if we told the user we would not provide a certain type of content (e.g.



audio) and failed, we would be in trouble potentially







shepazu: i understand where you are coming from, maybe rewrites can make it



clearer







olivier: a lot of the discomfort came from the spec being unclear. from today,



i recommend renaming it to "media file" capture







richt: a demo may help clear this up







<richt> richt: Josh_Soref has a demo that people should look at during the



break.







fjh: we have some more time, and have covered doug's concerns (though not



solved them)







... you believe that we should provide the ability to ask for more granularity







shepazu: yes, from a privacy perspective there is additional work needed







... also it would be useful to share discussion with the audio WG







... some overlapping members can help us discuss this







fjh: we should go thru the other comments now







Josh_Soref: (showing a demo)







... facebook, with a photo button







... on click the button, files are offered but don't want them. another option



is the selection of a new picture







... the same behavior applies to other recording cases







fjh: going to other LC comments







... 2641 was about front/back







anssik: this relates to the same discussion about audio/video... you should



use getusermedia instead







... 2637 is one we have to decide on, but not now







... 2640, about html will be easy to resolve







... 2638, asking for an example, we can say this is solved and do it with the



other comments of doug







... 2639, re camcorder as name, this seems not an issue anymore... any



objectors in the room? if not, propose that we close this one







<gmandyam> q







anssik: lack of speaking up means consent







nwidell: what is the relationship of the use of camcorder for getusermedia?







<Josh_Soref> [GetUserMedia][52]







<Josh_Soref> Access to multimedia streams (video, audio, or both) from local



devices (video cameras, microphones, Web cams) can have a number of uses, such



as real-time communication, recording, and surveillance.







fjh: they talk about tracks and streams, so they don't need to go there







... 2642 is done, not sure there was a response yet. we dont need to do



anything more until a response







... 2644, is addressed and done, and response is OK so this is closed







<AnssiK> LC-2644 +1'd by commentor at:



[http://www.w3.org/mid/001401cd96e5$7a73f7b0$6f5be710$@murthy@cmcltd.com][53]







fjh: two things needed to do, informative changes (any contributors welcome)







<nwidell> (intent of my question was just if there was a need to align



attribute names e.g. "camcorder" with somthing equivalent in getUserMedia







fjh: also to consider renaming it for clarity, possibly "HTML Media File



Capture"







bryan: is this just to be clear that a discrete file is delivered vs a stream?







<AnssiK> "HTML Media Capture" v "Media Capture and Streams"







fjh: 3rd things is to resolve the audio/video selection







bryan: they should be fine with the name, HTML makes it clear this is



declarative







anssik: also don't think we need to rename, they should be fine with this







fjh: so we are done with this?







### Vibration







fjh: would like to do more on vibration and wrap that up







... we were talking about how it couldn't be generic as not all platforms have



this feature, and testing







<AnssiK> [http://w3c-



test.org/dap/tests/vibration/submissions/robin/TODO.txt][41]







anssik: we have a todo list







... i volunteered to write the tests, welcome any support. also need some



hardware to test it on.







mounir: believe its in firefox OS







anssik: is there a way to emulate it somehow?







... will take it offline, and talk with tizen for testing







jungkee: samsung colleagues implemented this for webkit







fjh: so we need hardware and tests for vibration to proceed?







anssik: writing test cases is boring without hardware to test against







### Proximity and Ambient Light Sensors







fjh: going on to proximity and ambient light sensors







<spoussa> I can give AnssiK Tizen reference device for battery and vibra



testing.







gmandyam: the call for exclusions for ambient light just came out







anssik: we have one implementation for proximity events, and it shares the



design for ambient light







... at least for proximity, we could move to LC. marcos did the tests for it







gmandyam: Ian sent an email today for exclusion







<fjh> [Editorial Note, I checked this during the F2F and it is not an issue



for LC publication, completing ACTION-587]







fjh: need to know if the WG thinks the specs are stable and can move to LC







<AnssiK> * spec WD in Jul 2012: [http://dvcs.w3.org/hg/dap/raw-



file/tip/proximity/Overview.html][54]







<AnssiK> * test suite: [http://w3c-



test.org/dap/proximity/tests/submissions/marcos/][55]







fjh: who is involved with ambient light?







... can do a CfC







proposed RESOLUTION: publish a LCWD of the Proximity Events spec







**RESOLUTION: publish a LCWD of the Proximity Events spec**







fjh: it will be after the F2F when pubrules has been checked etc







<fjh> **ACTION:** anssi to prepare Proximity LC draft and run through pubrules



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action03][56]]







<trackbot> Created ACTION-587 - Prepare Proximity LC draft and run through



pubrules [on Anssi Kostiainen - due 2012-11-08].







<fjh> **ACTION:** fjh to review exclusion period for Ambient light [recorded



in [http://www.w3.org/2012/11/01-dap-minutes.html#action04][57]]







<trackbot> Created ACTION-588 - Review exclusion period for Ambient light [on



Frederick Hirsch - due 2012-11-08].







fjh: re Ambient Light Events, we should be ready for last call







<fjh> **ACTION:** fjh to send CfC for Last Call of Ambient Light Events



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action05][58]]







<trackbot> Created ACTION-589 - Send CfC for Last Call of Ambient Light Events



[on Frederick Hirsch - due 2012-11-08].







### Network Information API







fjh: Network Information API was not shelved







break for lunch







returning at 1:45 PM







<timeless> scribe: timeless







### Network Information







<adrianba> 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][59]







<Josh_Soref> adrianba: i've had an outstanding action for a really long time







<Josh_Soref> dom: one year







<Josh_Soref> adrianba: bad news, i may not be closing it today







<Josh_Soref> ... but i'm making progress







<Josh_Soref> ... this is about making a proposal for a network information api







<Josh_Soref> ... there was some disagreement







<fjh> [http://www.w3.org/TR/2011/WD-netinfo-api-20110607/][60]







scribe: one about reason for using it







... then there was a concern about bandwidth







... and whether the right network would be selected







... there were concerns about bandwidth determination and power use to



determine it







... W8 includes network info for applications







... what i want to talk about today is giving you an update of what we're



thinking







... what we've heard from app developers







... it may be inconclusive







... the main reason for this seems to be "Bill Shock"







... customer being billed for







... amount of data being used







... what we'd like is for applications







... to respect the kind of network







... and change their behavior







... this can be dealt w/ at two layers in the app stack







... one is for the system to make appropriate changes based on the network







... for the UA to make changes based on the network characteristics







... network perf of your site-web app







... will be better because UA did intelligent things







... app dev doesn't need to change any of their things







... to get benefit







... choosing to not precache video







... from a <video> element until someone presses Play







... in an adaptive stream media content







... it might be imposing a maximum on bandwidth for streaming







... in html







... we were talking about Responsive Images







... the browser might choose to download the smallest possible image for a



page







... if that might use less data







... this is us saying "we should try to design features into the open web



platform that can be intelligent"







... so when we're designing features







... let's be thoughtful about how the UA could change behavior for a Metered



network







... second is about APIs in this space







... for web application to do something intelligent







... it knows what it's trying to acheive







... we've had feedback







... we just want to provide the best experience to customers







... we don't want to degrade the experience to customers







... we don't really know







... for certain key, high volume, high value web applications







... they definitely want to







... applications they leave open for a long time







... social networks, web email clients







... developers of those apps want to do something







... am i supposed to be conserving bandwidth, or not







... that's the primary thing they care about







... for w8







... a place where we've got the experience / information available







... we didn't include anything in the app requirements to be aware of metered



networks







... it's purely up to them







... we have very few apps taking advantage of this right now







... there are 25







... written within MS that do use this







... considered to be an important part of the app







... related to the same scenarios as web sites







... long running applications that constantly talk to the network







... we have several MS owned web properties keen to take advantage of this as



well







... Outlook Web Access / Latest release of Exchange







... it supports mail offline in IndexedDB







... downloads messages or maybe only headers







... commonly part of installed thick client applications







... high value applications







... makes it different to figure out how to prioritize







... if it's only in IE, it's problematic







... from our research, i don't think we should write it off as a problem that



doesn't exist







... that people don't want to solve







... but perhaps it isn't the highest priority thing to work on in the group







... as deployment increases







... there will probably be more demand







... and we can look at this more highly







... interested to hear if people have heard the same/different things







fjh: i don't think Shelving is the right word







... shelving is "we want to do something different, but low priority"







adrianba: i think some of the concepts in the current proposals ARE WRONG







... i don't think trying to determine available bandwidth is useful







... trying to know if it's metered is useful







<richt> Opera on the Network Information API >



[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036116.html][61]







richt: i agree with a lot of what adrianba is saying







... comments from jgraham







... we have issues getting bandwidth numbers







... but what's at issue here is if it costs







... there's forking if you get Bandwidth info







... Mobile v Real web again







... uses are Streaming the right video







... it's not fork the user experience based on bandwidth







... there's some UCs here we want to solve







... but this approach is not optimal







... the implementations aren't great







... they're sort of hard coded, we could change it to get it right







... but we haven't got what it takes now







... I don't think Opera plans to implement this anytime soon







... we don't have to get bandwidth







... right now we're reporting back to the developer







... maybe we can report to the UA what it wants/needs







... that'd be more privacy preserving







<Zakim> bryan, you wanted to ask how does the UA know the network is metered?







bryan: if bandwidth calculation isn't worth the effort







... and primary UC is "is metered?"







... how does the device know the connection is metered?







adrianba: we in windows, we have Network Configuration that understands the



network we're connecting to







... the network is registered as a metered network







bryan: how?







adrianba: if i'm exporting a connection to a 4G network







... that connection has associated billing characteristics







bryan: how?







... through what specification







adrianba: this is a windows feature







bryan: this doesn't seem like an interoperable thing today







adrianba: how that gets configured to the device is out of scope







... i don't believe it's in scope for this WG







... happy to have that conversation about standardization, but not here







bryan: just is that a valid argument for shelving







adrianba: why can't every UA have a config option to say if it's metered?







bryan: users don't know ?







... number of reasons







... primary driver is to save money







... i'd say from our perspective, as a service provider







... facilitating more effective use of network resources







... probably a more important use of an api







... we'd like to take advantage of WiFi







... without knowing that







... we don't have any way for apps to make a decision







... how could an app indicate to a UA the type of network they'd prefer for a



particular network to be retrieved?







... leaving all decisions to UA/connection manager is problematic







... seems to be a gap in understanding true needs of an application







... content for particular resource







... and what would benefit a UA







... metering isn't the only UC







<Zakim> Josh_Soref, you wanted to point to Web Perf/Nav Timing/work on http



timing







<fjh> will scribe for Josh







Josh_Soref: to deal with bandwidth or source of information can look to web



performance wg to deal with this







... network performance will not just depend on network, could depend on



server, country it is etc







... not every network is metered







... agree with what adrian has said







... user agents improve since they can get this information/







<bryan> you may know the overall plan that you have, but knowing where you are



in that plan in the current billing cycle is likely impossibe







Josh_Soref: can tell if on wifi or cellular by using DNS







dom: who do you know by DNS







Josh_Soref: DNS record for phone will say network







... reverse DNS lookup gives different host domain







dom: worldwide?







Josh_Soref: improvements needed to some network providers







<bryan> is the DNS approach a standard or enforced?







<bryan> so the UA needs to use the DNS protocol to know?







<Zakim> mounir, you wanted to ask if keywords would be more interesting?







Josh_Soref: no, the server side can do the DNS lookup







<bryan> how does the UA know that the app wants a specific content delivered



via WiFi?







mounir: about type







... i don't think we should show that for privacy reasons







... it adds bits of finger printing







... it helps tracking people







... you can try to guess where they are







... i don't think there's a real UC for knowing the type







... most of the time







... "we want wifi" because "we want fast network"







... they don't really care if it's wifi or 4g or cable







... they want fast







<bryan> re type, josh just said that this is easily discoverable via DNS, so



avoiding providing this information locally provides no additional privacy



value







mounir: about metered, as Josh_Soref said







... it's hard to do right now







... but it's easy to improve







... if we have a Spec for that







... it's easy to improve later







... as MS is doing to push carriers







... and about bandwidth







... we may still have UC for that







... i think some apps might want to save bandwidth if you have low battery







... regarding UX it might be better







... i wonder if checking battery to something accurate







... to KB







... to track if you're slow or fast







... might solve some issues







... and keep the feature







<bryan> so how easy to improve? as a deployer of device management (the only



feasible approach to get metering info as a standard), I can tell you that



even static info provisioning is complex







dom: what's the UC for bandwidth?







... adrianba said research showed







... no real use for this







... do you have concrete UC







... or know of real apps that would use it?







mounir: i don't have an example of an extension using that







... we could make up one







<bryan> getting dynamic metering info (where you are in the billing cycle, or



how specific resource would affect your plan) is even more difficult







mounir: but for Battery API, there's a argument of no UC for it







... but if i don't have such a feature, then.. how can you use it?







... it seems like a chicken-egg problem







... i'd appreciate if my email client doesn't fetch body on low bandwidth







dom: does firefox os have this?







mounir: no







sicking: when we started this work







... we spoke to PhoneGap







... and asked what apis people asked about







<bryan> josh that is not correct, small packet transmission has a much



different power profile







sicking: they said a big request was for Edge/WiFi/3G







... they had a bunch of apps that wanted to know







... if they had a high bandwidth video and a bad connection, they knew it was



going to fail







<AnssiK> PhoneGap's Connection API: [http://docs.phonegap.com/en/edge/cordova_



connection_connection.md.html#Connection][62]







sicking: their UC was to avoid initiating a network connection if it was going



to fail







... if you want to avoid doing connection, you've already lost







<AnssiK> [PhoneGap aka Apache Cordova]







sicking: no particularly strong UCs for WiFi v. Ethernet







... not even 3G v. WiFi







... but Edge v. Other stuff







... same thing w/ online v. offline







... you can argue it's useless







... we still have it







Josh_Soref: because you can't get rid of it







dom: just relating what adrianba said







mounir: adding Type







... some people seem to want it back







... before my proposal







... there were property name for connection







... "If 2G or 3G, we're slow"







... i doubt 3G is "always slow"







... wifi can be way more slow than 3G







... which helps for UC







... adding slow connection







... a better UC for bandwidth is Games







... if you're playing games







... you may want low bandwidth







gmandyam: talking w/ a Qualcomm hat on







... we do know there are many situations







... just because you have WiFi, doesn't mean you're getting an increased



throughput







... while you're staying in the same location







... developers making a decision based on that







... are not always going to make the right decision







Josh_Soref: +1







gmandyam: even though bandwidth estimation isn't passed







... at least on a handheld device







... if it isn't matching the modem estimate







... it isn't good







<bryan> "not always making the right decision" is certainly true, but is that



the objective, or is it to address the majority of use cases in which it would



be the right decision?







gmandyam: it's a MUST that browser vendors do this with the chipset vendors







... if they're not able to do it, it isn't a worthwhile feature







... OMA is actually looking into similar activity







... they just standardized a Connection Manager API







... they're talking about a JS API







... a readonly API







... we doing it, they doing it, will cause confusion







... like to see that resolved







fjh: [ adrianba left ]







... need to make time for web activities/intents







... do we shelve/discuss?







... after bryan + Josh_Soref, maybe straw poll?







bryan: key points







... we shouldn't let the perfect be the enemy of the good







... this is definitely a valuable feature







<dom> [my sense is that there is rough consensus that "metered" is a useful



feature; bandwidth/type is more controversial at this time]







bryan: network operators want apps to be smarter







... they want apps to have a consistent experience







... if not addressed in W3C, it'll be addressed somewhere







... i'd prefer the open web to develop it







... connectional information is important







... rather than telling the App what it can know







... if the app could tell the platform "this is what i would like"







... "deliver this over WiFi"







... dropping everything because some things could be done







<Zakim> Josh_Soref, you wanted to note that bandwidth has little relation to



power use, if you get the data in a single packet, or stream of consecutive



packets







<dom> [I think the "deliver this over WiFI network" would be in scope for an



entirely different API, which I can't assess from the top of my head whether



it would in scope for DAP]







<fjh> Josh_Soref: if you receive multiple packets at one time versus



individually power usage will be less , if the radio only turns on once







<fjh> Josh_Soref: thus shouldn't second guess efficiency of implementation and



if apps try to manage this then it might not work so well







<fjh> Josh_Soref: deliver over unmetered can be in srcset specification







<fjh> Josh_Soref: agreeing with adrian here







<dom> (@srcset is a very specific and limited use case for metered)







richt: progressive enhancement







... by giving web page, we're assuming web pages to know what to do with it







... by giving web page the information







... we're letting the pages create a 2 tiered scenario







... we want to be able to let metered UC handle







... it doesn't have to be in JS







... it could be in HTTP headers







... it could be a button in UA







<bryan> leaving apps with no usable contextual info also creates a two-tier



situation, in which developers are assumed to be stupid and browsers assumed



to be all-intelligent







richt: "turtle" throttle from this point onwards







... there's lots of different ways







... i don't think we're at a solution







nwidell: after this, i think we need a better understanding of UCs







... there's Bill Shock







... bandwidth Adaptation







... which can be done server/client side







<fjh> potential action on proponents of use of network information API to



document APIs







nwidell: i don't think we should shelve it right away, get UCs first







fjh: i don't think we should shelve it right away







... i think we should get UCs documented







... i think on the home page we could put a notes saying this group is still



reviewing spec







mounir: we should make clear there's two specifications







... people get confused







AnssiK: /tr doc is out of date







dom: we should update /tr







mounir: i can do that







dom: updated working draft saying we're exploring the space







... bandwidth has Issue







... metered seems interesting







... putting UC in this







... i'm happy to put note







mounir: i can add UC section to spec







jcdufourd: please







fjh: published TR is out of date







... best way to publish updated WD







... create updated WD, publish, update SoD







... make clear it's under discussion







... updating UCs







... i'll give an action to do that to mounir







... dom can help







... and we agree to publish updated WD







... any objection to publish updated WD







<richt> The use cases are important but we might be able to find a better



solution.







<richt> e.g. provide a 'turtle' icon in the UA. The user can click it when



they are in a low-bandwidth network or on a metered network (or the browser



can set it based on network changes itself). Then the UA sends an indicator of



this setting in a HTTP header for subsequent requests until the user/browser



switches it off.







**RESOLUTION: Publish updated WD of network information**







fjh: nothing else required for publication?







dom: people may want to see draft before







<fjh> **ACTION:** mounir to prepare updated WD of network information with



updated status, including addition of use cases [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action06][63]]







<trackbot> Created ACTION-590 - Prepare updated WD of network information with



updated status, including addition of use cases [on Mounir Lamouri - due



2012-11-08].







<fjh> we will share draft in group for review before publication







dom: nwidell are you offering to help w/ UCs?







<fjh> nwidell: yes will help with use cases







dom: don't be blinded by solution, focus on documenting problems







fjh: mounir, when can you update the draft?







mounir: within a month?







### Web Intents/Web Activities







fjh: unfortunately, my flight was delayed a day by #Sandy







... GregBillock, i'd like to go through the issues







... understand web activities







... understand fundamental differences







... figure out what group wants to do?







... go from there?







GregBillock: current Chrome impl... i could show again







... it takes time







... current state, it's behind a flag in Chrome 24







... you go to chrome://flags and enable







... web intents from there







... implementation, mostly UI issues







... they're significant enough







... they're potentially needing api issues







... there are different dispositions for Web Intents services







... one is to render inline on top of the existing invoking tab







... kind of the experience -- tab modal dialog showing service







... backed by browser, overlaps location bar a bit







... you can tell it's a different surface than the original tab service







... you're still in the same task context as it were







... nice because it's related to what you were doing







... but it's a bit more difficult to adapt existing web apps to conform to



that







... we decided to have a window disposition







... basically multiple tabs working on the same intent







... difficulty is letting user know this is what's going on







... couple of edge cases







... imagine editing a document from one tab







... if you close that







... and editor doesn't have a way to persist your changes, you can lose them







... we have a general concern







... if user isn't comfortable using tabbed browsing







... they might not understand this two tab thing







... the other one i talked about yesterday







... is the issue...







... initially we imagined the Service Picker







... we didn't want to expose what the situation was w/ installed services







... we wanted to leave open for the browser to let the user discover new



services in the picker dialog







... that's worked out a lot less well than we thought they would







... users are a lot less comfortable with extensions







... don't understand what's offered







... the workflow w/ 4 steps deep install + authenticating







... it interrupts flow= bad experience







... that's a more significant challenge to the way we envisioned the feature



working







... we may be after a way closer to the way hixie proposed on WhatWG







... closer to RPC/RPH







... semantically, users choose an application to fulfill service







... bypasses the need for showing service selection dialog







... that service selection process would have fewer problems







... not saying we should do that







... but...







... the UI problems we came up w/ have an impact on how we view semantics /



how we shape the api







... not sure that's the solution







... it's not just something the Chrome UI people will sit down and solve







... but it affects the API level as well







... those are the main points







... a couple of things we've discussed in Intents list







... are making things closer to hixie's proposal







... and web activities







... changing window.intents delivery







... we assumed we'd always do intent delivery to a brand new context







... based on feedback from people who wanted to use the feature w/ an open



application







... even if we kept the existing spec







... we'd want to make changes like that







... using a message to do delivery instead of window.intent







... and another thing is mirroring the RPC api for intents







gmandyam: i'm confused as to what you found in chrome







... how that impacts the normative text in the spec







... normative text doesn't get into UX







... also







... i haven't personally tested out explicit intents







... shouldn't that really be the fallback?







GregBillock: nothing in the normative text in the draft text reads on the UI



in the browser chrome







... the way they feed back







... users should be using web intents because they're easy to use, easy to



discover







... but they find the selector dialog confusing







... intimidating







... since that happened, we're considering perhaps not the same api







... if we change how we imagine connecting services







... we might have a different api that does that job







... it's possible we'd have a more navigation based solution







... if we have a mechanism that treats primitives of app construction







... the way they can be addressed in construction







... take an example







... i have an offline enabled app that supports a photo sharing site







... there's a button in it "please share this photo"







... you get a page in that app that does sharing to that service







... but the way you get to that is through a navigation transition







... it could be a different api







gmandyam: seems like it's part of a broader problem







... part of it is a discomfort with web stores in general







... which is part of why i think it's a mistake to consider modifying the



proposal







GregBillock: there are some who'd rather things closer to bookmarks than a web



store







... perhaps goes to sysapps







... think of what the right solution is







gmandyam: while we wait for better user acceptance of web stores







... we should make sure explicit intents is properly implemented







GregBillock: explicit intents







... is an important ingredient







... it wasn't there at first







... it was one of the things that jumped out of this







... a lot of people saw intents as important for transitions within their own



applications (beyond just cross app)







... i agree that's important







... direct invocation







... -- web apps that are composed of elements that can be linked to







... my best guess is that a navigational metaphor is the best way to think of







... just an intuition







AnssiK: have you prototyped window-disposition in small phones?







... in small screens, it just doesn't work







... it kind of works on big screen







... but for mobile, it seems awkward







GregBillock: good question







... we hadn't done any on small screens







... our idea for how that'd look







... if you look at Chrome on Android and how tabs are there







... you'd transition







... they'd be "tabs", but presented in a full screen







... just as all "tabs" are in Chrome for Android







... in some ways that's an easier UI to solve the problem







... in terms of confusing UI







... on a small screen, you don't have the same opportunity for confusion







... about what not to touch







... a small screen ends up being modal







... for users who don't care about mechanics about who's operating screen when







... it's always overlapped/inline







... those problems are "easier" to solve







... if anything, small screens were easier







... the tricky worries come up w/ multiple tabs on larger screens







AnssiK: what's your message to developers relying on the current web intents



api?







... developers get mad







GregBillock: we're going to post a message on WebIntents G+ group and



discussion forum







... letting people know we're putting it behind a flag







... the implementation is limited to apps in the store







... so we have a fixed list of services to speak to







... not a lot of web content relying on the existing impl







... we experimented with Chrome







... and were finding workarounds internally







... not sure about reaction of putting behind a flag







... it was vendor prefixed







... that's not something vendors understand







AnssiK: i wouldn't be surprised if it made headlines in HTML5Weekly







<Zakim> fjh, you wanted to ask about privacy and user interaction







fjh: GregBillock, you said Usability testing







... showed they couldn't handle the selection







... but i thought that was what we used for privacy control







GregBillock: UI problems







... relying on UI to guide normative parts







... the thing we were talking about w/ Store model







... people decide to adopt a particular app







... probably because they know the vendor/institution







... and they invest agency in that app







... that bundles trust transactions







... once they decide to use an app







... they accept the permission bundle







... there are people eager to do that because it makes their browser



experience better







... some don't understand what it means







... people can opt out







... We saw use of Selection for Discovery wasn't working as well as we



expected







... it's long, involves authentication







... you lose track of where you were







... trying to use that capability to get this job done







<Zakim> bryan, you wanted to ask what info suggests users are uncomfortable



with web stores







bryan: gmandyam mentioned users not adopting web stores







... what indication is there to users not adopting them?







gmandyam: i was asking that







... it seems like GregBillock confirmed that







... classic users with some confusion







... i agree w/ bryan, there's no Google Play version for Android today







... a large segment of users who can't use it







bryan: i see some people have developed a way to load extensions in their



system







... i don't see activity to build market







... it makes sense to simplify UX







... i'm wondering how the shift from the UI experience







... would affect discoverability







Claes: having 2 tabs, one for client, one for service







... what about just having the service application in the same tab as the



client, just replacing the client application







... which means he can't close the client app







... other was about the picker







... as i see it, it isn't just about picking, but also trust







GregBillock: one possibility is to think about







... intent invocation is a navigation transition in the tab







... that's a fruitful way to think about this







... there's also a big implication to the api







... the current API isn't navigational







... there are a lot of exciting aspects







... i'm not sure if we should model it as navigation







... those are the implications for normative part of spec







... if we want to go with a different api







... if a user frequently goes to Flickr







... that's a suggestion that they have a photo they're about to save







... if you visited Flickr 60 times in the past month







... that's at the top of the list







... a web site could say







... i want to use this site for Email, Photo Sharing, Saving Documents,



Editing Pictures







... when that gets selected







... that changes the default







... the current experimental prototype







... in 24







<fjh> break until 4 pm (35 min)







### Web Activities







mounir: should i show the api?







<mounir> [https://wiki.mozilla.org/WebAPI/WebActivities][64]







<mounir> [http://lists.w3.org/Archives/Public/public-web-



intents/2012Jun/0061.html][65]







mounir: a url for the api, and one explaining why







... we had to do something that looked like web intents for Firefox OS







... we thought Web Intents wasn't the correct solution







... and we needed something fast







... it was close enough







... in my opinion







... one of the issues we had







... Web Intents in the current specification (as of June)







... allowed you to do a lot of stuff







... people were using it to do a lot of stuff







... APIs based on web intents was something we thought shouldn't happen







... if you want a good UI







... you need a constrained UC







... e.g. trying to Run a web Intent that shows nothing







... would be really hard to do







... we tried to restrict that







... Web Activities







... has to have a UI







... we assumed that the UI was clear







... in Firefox OS







... if there's an activity handler







... we show that App for the Activity







... if the activity is doing nothing, user says "what's this app doing" and



stop using it







... that Web Intents allowed communication between App A and App B, we tried



to prevent that







... in Activity, an Activity returns a value or not







... a UI issue we had







... a new activity







... that was expected to return a value, like Edit







... the UA would have to return that value







... if the value would never be returned, we should fire an error







... to know if the activity would return a value or not, we had to know that







... the boolean for returnValue... is for UI purposes







... we don't have a type attribute in ActivityOptions







... most don't need type







... it was confusing web developers







... if you create an SMS, what type do you pass?







... inventing new types doesn't make sense







... type has to be in the data object







... technical difference in how you create an activity







... the Navigator bit isn't implemented yet







... Web Activity is only implemented for Apps in Firefox OS







... we found issues that are different than what the Chrome team found







... i was telling GregBillock , web activity is interesting for a web os



permission thing







... if an app might want to send an sms, it might not want to ask for



permissions







... Today, Firefox OS only allows builtin apps to send SMS







... for a trusted app to send an SMS, you have to use an activity (today)







... for permission, you call that actiivity







... we go to the SMS app UI







... so you might understand you're going to send an sms







... and you'd have to press the Send button







... to avoid the user not being aware of sending the sms







... we need the App and Activity to follow this rule







... there were internally issues for this







... for the Telephone activity







... having to press the Green call button







... for security reasons







... even if we put as much restriction we could, we still had to rely on apps



to be good citizens







... even more if you give them permissions







... things we found







... GregBillock mentioned window.intent and switching to DOM Event







... for Firefox OS, we're using System Messages







... if you send a DOM Event







... making a process to add an activity







... the app might still be open, or might have closed







... i might need to run the app







... if i run the app, and want to send a dom event







... it has to be clear when to send the dom event







... otherwise if the app registers too late, it might miss it







... after load might take a long time







... it was a problem







... too-hard to solve using dom events







... System Messages are like DOM Events







... or window.intent







... it's sent by the system







... if the target isn't awake, the system will wake it







... and those messages will be Queued







... if there's no handler, they'll wait for the handler to come







... the app can check at any time during load







... so they can prepare the UI







... and then they can register for the system message







... when they return to the event loop, we'll call that handler as many time



as message are waiting







Josh_Soref: is it a Queue or Stack?







sicking: it's a Queue







mounir: this mechanism is only for Firefox OS







... we will push that in Sys Apps







... we don't know if it will be for regular web content







... what we defined is how to register







... but we haven't implemented it







... we might just use system messages







... regarding Registration







... using Intent inside the body







... right now, Firefox OS just uses the App Manifest







... to register for Activities







... since that isn't for web content







... we haven't decided how to do that







... i'm not a fan of in the <body>, but inside the <head> is understood to be



painful







Jungkee: i'm working on two WebIntent specs







... delivering data from server side to client side







... trying to use two activities







... we have many UCs to deliver data from one to another







... in the Pick an Image from the mozilla wiki page







<Josh_Soref> [Pick an Image][66]







Jungkee: how do you pick an image if you don't have communication between



receiving web app and service







... we want to allow application to application data delivery







... mounir 's explanation in web activities, they don't allow that kind of



communication







... ?







mounir: we allow an activity to return a value







... we don't want to allow app A and app B to communicate for an unlimited



time frame







... a return value activity in the browser is hard UI wise







... as soon as PostResult is done,







... the UI is simple







... for closing the activity







... if there might be more activity, we don't know how to handle the UI







... what to show is undefined







... there are UCs where people want a View activity for a TV







... and App A controls play-pause







... we think that could be solved w/ another API







... and not activities requiring UI







Jungkee: i understand activities from ui side







... about pick media intent







... have you tried pick media intent/pick contact intent?







... from service page, we're picking contact information/media files







<dom> [Pick Media Intent][67]







Jungkee: those two specs are now using picking some data payload







... service to client side







<dom> [Pick Contacts Intent][68]







Jungkee: in my opinion right now, we can't avoid some user interaction







... the user interaction between the ui page/tab/window/inline







... to an application page







... that kind of activity is something that i'm thinking about







... we talked about the UC







... we've been working on it w/ some demos







... do you have opinions?







mounir: i'm not sure i understand







... what activities allow you to pick media files?







Jungkee: does it allow ui thing?







mounir: we want to prevent stuff happening in the background w/o UI







... we always want a UI







... if you have a pick activity handled by gallery







... you use pick, gallery handles it







... gallery appears, you interact







... you pick, it returns







... gallery closes







... we implement File Input like that







sicking: we use activities to exactly this flow in Firefox OS







... it is working







fjh: similar question about UI stuff







... in web intents, we use user interaction for privacy/involve user







... do you have interaction as part of it?







... examples don't seem to involve user







... every web activity involves user







... have there been usability issues







... or does it fall out naturally?







... indication that it's usable?







... is usability a concern here?







mounir: we always want a ui







... it's displayed,







dom: does the work flow of Web Activities







... does it work for Users?







mounir: we had a different experience than chrome







... because we only used it for Firefox OS







... but the user experience is very similar to Android







... Android experience isn't awful w/ Intents







fjh: Web Intents lets you have access to resources anywhere







... not just on device







<npdoty> is there documentation about why Mozilla is pursuing this only for



Firefox OS? what are the reasons for not using this in Firefox for Android or



on desktop?







fjh: request needs some service







... is web activities just the device?







mounir: it's more broad, but right now it's just the device







... there is a registry







... of which apps can handle an activity







... but right now it's limited to installed apps







... if you visit flickr.com, we could add that







<npdoty> ah, I see, so it's just that the registry handler is disabled for



non-installed apps?







gmandyam: afaict, when i compared specs side by side







... you aren't depending on Web Messaging







... you didn't want to have Ports, and keeping Ports open was difficult to



manage







mounir: we don't use Web Messaging/Ports







... because it's hard to manage UI wise







... we'd be interested in pushing a discovery API







... to allow background services







gmandyam: since web activities works w/o a dependency on web messaging







... and most web intents don't leverage feature of web messaging







... why did we need web messaging?







... maybe it might be better to define intents w/o web messaging?







... until browsers better handle on this problem?







GregBillock: i was going to talk about exactly that







... for Intents, the expected UC is that the structured clone doesn't have



ports







... structured clone supports transferables







... but you need Ports to do some of that







... the argument for using structured clone is the same as it has always been







... if interapp communication supports structured clone, it's maximally



supported







... you get blobs transferably







... but you can't transfer ports







... you get unpredictably about interaction between contexts







... the right path forward might be to forget structured clones







... we might only support a subset of structured clone







... the difficulties of port exchange are such that it's tempting to not do it







... we might use urls







... and a separate system for some of that







... richt may have an idea







... about Pick Media in Intents v. Activities







... i think it can be trivially over either







... same vocab for both







... some communication mechanism as opposed to more specific







... same problem as Get User Media and Media Pick







... in one, it's "please get me a contact"







... but the application you're talking to, needs some api







... it may use its own contact store (IndexedDB) or its own api over the api







... if there are contact repositories on the device







... there are UCs where you want more high level integration







... sometimes it's useful to have a low level integration api







... apps responsible for receiving it







... need a way to do, e.g. Get User Media







... i'm not sure that having high level means you don't need low level







... just different levels of abstraction







<Zakim> jcdufourd, you wanted to comment on assumption that you can kill the



service provider page as soon as it has returned a value







jcdufourd: mounir, you said it isn't ok to pass a message channel as a return



from a web activity?







... because you want to be able to kill the service provider when it returns?







mounir: no, it's because i want to know when i'm done w/ the activity







... for the ui







... otherwise we can't build a good ui







jcdufourd: what if you have multiple registrants for an activity?







... what they solved w/ a picker?







mounir: we have a similar UI







... i haven't seen it







... it should look like the Android UI







... to show activity handlers







... we have some security rules







... to prevent activities to register/be open for certain things







sicking: one thing we're cheating







... but because we're only solving on small screen devices







... Chrome is dealing w/ a browser UI







... tabs have a special meaning







... all independent, user is in full control







... all rendered "at the same time"







... we're solving in "you're only showing one app at a time"







... starting an activity replaces the other app







... leaving an app cancels an activity







... we didn't implement this for web pages







... because of UI issues







... a lot of experimenting needs to be done







... i don't think Activities v. Intents makes a lot of difference







nwidell: it sounds like there's technical difficulties to Ports







... long lived







... but by abstracting a lot of interaction parts







... keeping a clean interface between client+server







... we've discussed sensor UCs







... it's a way to connect sensors that may not always be available







... available through some kind of message protocol







... if we remove ports







... we'll need to consider a replacement mechanism







... for long lived







jcdufourd: re sicking







... this isn't implemented for web pages?







sicking: this is only implemented for Firefox OS







... for our Application Platform







... only Installed Applications







<Claes> +1 for nwidell's comment







sicking: can be handlers for Activities







... web pages can invoke a Pick Activity







... but it can't handle one







jcdufourd: you've implemented service providers in HTML/CSS/JS in a browser



like context







sicking: i'm distinguishing Web Apps from Web Pages







jcdufourd: only in the context of small screens?







... is it applicable to the wider context of web intents?







sicking: it needs to be experimented with







... we'd have many of the same unsolved questions as Web Intents







... one issue is seeing two tabs rendered







... the first tab is still there







... you can switch between them







... user can open a new web page







... we'd have these problems in Activities







mounir: for us, there's only one App (shown at the same time)







... if an activity is handled of App A







... there's only one instance of App A







<npdoty> the small screen is essentially modal







mounir: if it were to be handled by Flickr.com, which window handles it?







... a new one?







<Zakim> dom, you wanted to interest on background services







dom: thanks, that clarifies a lot of things to me







... i'm not clear if we can converge activities with intents







... not sure if we have hopes for solving the UI







... a separate background API could solve UCs that have been brought up







... i know there are UCs for this







... I know Web Intents was meant to solve this UC







... but it seems it isn't safe to assume that







... should we start forking Intents or,...







... to work on this set of UCs?







GregBillock: initially we called that Hidden Disposition







... like a Web Worker







... that could respond to Web Intent invocations with a result







... requiring no ui surface







... trying to think about how that'd work







... we didn't find a good UI solution for that







... there are definitely reasons it'd be nice to have







... we're not sure how to present that







... for installed apps, it's a bit easier to imagine how it's solved







... there's already a trust for that







... but for web content at large, it's frightening







... to imagine getting access to a sandbox without a task manager







... we haven't cracked that yet







<bryan> +1 to starting discussion on a background service API







mounir: i drafted quickly an api for that







... we haven't implemented it







... and not soon







... if there's interest







dom: that would be a good idea







... not sure about sooner or not







... getting ideas cannot hurt







... it might clarify information re: network discovery proposal







... how these fit/don't together







bryan: that proposal would be one we'd be interested in talking about







... in web & tv, there's interest in using IndexedDB as a filesystem







... but the restriction on origin is problematic







... on an opt in







... to faciliate a virtual file system for web apps







... could be nice







richt: we'll talk about network service discovery tomorrow







... we've talked about ongoing services using urls







... we've looked at allowing a web page to advertise itself as a network



service







... but a flag that it's only available on this device







... say for network, or only for device







... it's all client JS







... two tabs







... create background long running communication







... based on URL created by UA







... the URL allows HTTP semantics







... page dies, we can send timeouts







... part of HTTP stuff







... but also flicking a flag to allow other devices to connect







... it's exciting







fjh: thanks, this has been very helpful







... what can we do pragmatically







... GregBillock, you're still working on it?







... mounir, you have a non-contributed spec







... Jungkee mentioned looking at our pick spec







... you said it'd be straightforward







... sicking was saying the UI problem wasn't solved no matter what







... what should we do?







GregBillock: we could come up w/ ideas







... but it'd be hard to import into Chrome/Firefox UI process







... it isn't a very satisfying message







fjh: it makes sense







... we want wide interop adoption







... will this outcome mean interop implementations?







GregBillock: that's the goal







<richt> Scribe: richt







<dom> scribenick: richt







GregBillock: I think there is commitment there that we can work together on



this.







... the optimism is well-founded. It's an encouraging prognosis.







mounir: I agree. Our goal is to have an interoperable implementation.







... we don't want to stay inside walls.







dom: So what are the next steps? actions?







GregBillock: We're going to be talking for sure.







... There are other profitable directions to think about.







... We need to think about some of the ideas like navigation.







... Some of the things richt was talking about reminded me of that.







... e.g. HTTP semantics.







... I could be totally wrong about that direction but if someone is sitting on



a great idea about how that will work in an instant way then we'd be excited



to hear about it.







dom: Another question. A lot of people have heard about Web Intents. We have a



Working Draft.







... Only very few will hear about the discussions we've had over the last few



days.







... What can we do with the existing draft to make it clear where we are at



with this?







GregBillock: It's on us (the draft editors) that current status is correctly



reflected.







... and the way to make progress here.







... That is all going to be happening soon.







... We wanted to talk in DAP about this stuff before we sent all that info



out.







... Make sure we're saying things that the WG is agreeing on.







fjh: If GregBillock and mounir could discuss this soon then we could put out a



collaboration announcement aka. making progress on this stuff.







GregBillock: We've put our implementation behind a flag. There's still a lot



of thinking and problem-solving going on







... We'll see what the outcome will be here.







... Part of that whole process will be based on discussion we have on the



mailing list.







nwidell: Require a clarification: Are we removing long-lived connectivity from



Web Intents?







fjh: Presume we wouldn't need another mailing list for this?







dom: That's in scope for DAP







fjh: What would happen to the work you're doing richt







richt: We've been coming at this from a different angle...







... We've realised we have a good opportunity to do long-lived background



process stuff via the discovery spec with the addition of e.g. register



functions.







... we'll be talking about that soon and hope to add something to the spec



there so there may be some overlap.







### Agenda review







fjh: I've updated the agenda for tomorrow.







... Start time is currently 9am.







... On request we're moving Network Service Discovery to the morning session.







... After lunch we'll be talking about signage, pick media and calendar.







... We'll be briefly talking about Media Capture and Sensors.







<timeless> /me looks like around 9am







fjh: We wanted to talk about CoreMob a little also.







dom: We have a few people in the room that are also involved in CoreMob.







fjh: At the request of Cathy (due to TZ differences) could we move Network



Service Discovery to just after lunch?







<npdoty> I don't think lunch is served until 12:30







[ negotiating a time to talk about NSD tomorrow ]







scribe: we'll start Network Service Discovery discussion at 1pm CET tomorrow







Agenda for tomorrow:



[http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France][3]







Jungkee: Do we have 30 minutes left to talk about Pick Contacts Intent spec?







fjh: Probably not time today.







Jungkee: Hope to get consensus tomorrow in the meeting. I would like to show a



Pick Media demo now.







[ Jungkee makes a demo of the Pick Media Intents Addendum API



[http://www.w3.org/TR/2012/WD-gallery-20120712/][69] ]







<npdoty> that confusion is indeed an excellent example of the UI problem



discussed earlier







<dom> hmm... is it? (it does illustrate a potential problem, but not sure that



matches the one previously discussed)







<Josh_Soref> sort of







<Josh_Soref> in average use, the client and service would have very different



visual style and content







<dom> right







<Josh_Soref> and the service would show content relating to what it's likely



to offer







<dom> (a potential problem would be a provider trying to blur that



distinction)







<Josh_Soref> whereas the client would have stuff relating to what it was



trying to do (and thus that it needed something)







<npdoty> can the user tell the difference between an Intent that is in



progress and creating a new tab via window.open()?







<dom> ah ok, fair point







<Josh_Soref> npdoty: at this point there is a ui indicator in Chrome







<Josh_Soref> specifically the urlbar has a "change provider" button







<Josh_Soref> beyond that, not really







<Josh_Soref> plus, i'm envisioning intermediate Intents







<Josh_Soref> which are both services and clients







<Josh_Soref> e.g. if i want to pick - video/mpeg







<Josh_Soref> and i have a "make video from slideshow" intent - if that make



video from slideshow app is built by using a pick - image/* intent; then i'll



click one pick video/*, which loads a tab, and click one pick image/*;multiple



which loads a service picker where i choose the gallery which opens in another



tab|







dom: Sounds good but I don't want to get in to the discussion about e.g.



specific fields in my address book.







... that could get too complicated.







Jungkee: meta data provided by Pick Contents would be very useful for a lot of



services.







... Now I'll quickly show the Pick Contacts Intent demo.







[ Jungkee shows a demo of the Pick Contacts Intent Addendum API



[http://www.w3.org/TR/contacts-api/][70] ]







Thanks Jungkee







npdoty: We have an informal meet-up tonight with privacy folks for a few



drinks for those interested.







fjh: Anything else we need to do today?







<npdoty> privacy get together at 7pm downstairs in the lobby, drinks and maybe



dinner too







<npdoty> everything will be off the record, thx dom







[ reviewing today's actions ]







<fjh> Thanks for scribing Josh, Rich and Bryan!







[ meeting closed for the day ]







<fjh> **ACTION:** gbillock to work with mounir to create new webintents draft



that reflects web activities and issues [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action07][71]]







<trackbot> Created ACTION-591 - Work with mounir to create new webintents



draft that reflects web activities and issues [on Greg Billock - due



2012-11-08].







<fjh> **ACTION:** mounir to Work with Greg to create new webintents draft that



reflects web activities and issues [recorded in [http://www.w3.org/2012/11/01



-dap-minutes.html#action08][72]]







<timeless> s/giri:/gmandyam:/g







<timeless> s/claes:/Claes:/g







<timeless> s/anssi:/AnssiK:/g







<timeless> s/anssik:/AnssiK:/g







<timeless> s/jcdofourd:/jcdufourd:/g







<timeless> s/jungkee:/Jungkee:/g







<timeless> s/wonsuk:/Wonsuk:/g







## Summary of Action Items







**[NEW]** **ACTION:** anssi to prepare Proximity LC draft and run through



pubrules [recorded in [http://www.w3.org/2012/11/01-dap-



minutes.html#action03][56]]







**[NEW]** **ACTION:** dom to review Battery test and contribute more tests



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action01][35]]







**[NEW]** **ACTION:** fjh to review exclusion period for Ambient light



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action04][57]]







**[NEW]** **ACTION:** fjh to send CfC for Last Call of Ambient Light Events



[recorded in [http://www.w3.org/2012/11/01-dap-minutes.html#action05][58]]







**[NEW]** **ACTION:** gbillock to work with mounir to create new webintents



draft that reflects web activities and issues [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action07][71]]







**[NEW]** **ACTION:** mounir to prepare updated WD of network information with



updated status, including addition of use cases [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action06][63]]







**[NEW]** **ACTION:** mounir to Work with Greg to create new webintents draft



that reflects web activities and issues [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action08][72]]







**[NEW]** **ACTION:** richt to review Battery tests [recorded in



[http://www.w3.org/2012/11/01-dap-minutes.html#action02][36]]











[End of minutes]







* * *







Minutes formatted by David Booth's [scribe.perl][73] version 1.135 ([CVS



log][74])







$Date: 2009-03-02 03:52:20 $







   [1]: http://www.w3.org/Icons/w3c_home







   [2]: http://www.w3.org/







   [3]:



http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France







   [4]: http://www.w3.org/2012/11/01-dap-irc







   [5]: #agenda







   [6]: #item01







   [7]: #item02







   [8]: #item03







   [9]: #item04







   [10]: #item05







   [11]: #item06







   [12]: #item07







   [13]: #item08







   [14]: #item09







   [15]: #item10







   [16]: #item11







   [17]: #item12







   [18]: #item13







   [19]: #item14







   [20]: #ActionSummary







   [21]: http://www.w3.org/2009/dap/







   [22]: http://lists.w3.org/Archives/Public/public-device-



apis/2012Oct/att-0014/minutes-2012-10-03.html







   [23]:



https://www.w3.org/2000/09/dbwg/overlap?ids%5B43696%5D=on&ids%5B58119%5D=on







   [24]: http://www.w3.org/2009/dap/track/issues/126/edit







   [25]: http://www.w3.org/2012/09/sysapps-wg-charter







   [26]: http://w3c-test.org/dap/battery/tests/







   [27]:



http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API







   [28]: http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html







   [29]: http://dvcs.w3.org/hg/dap/log/tip/battery/Overview.html







   [30]: http://nightly.mozilla.org/







   [31]: http://w3c-test.org/dap/battery/tests/submissions/anssik/







   [32]: https://developer.blackberry.com/html5/apis/blackberry.system.html#.e



vent:batterystatus







   [33]: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-



created.html







   [34]: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-



interface.html







   [35]: http://www.w3.org/2012/11/01-dap-minutes.html#action01







   [36]: http://www.w3.org/2012/11/01-dap-minutes.html#action02







   [37]: http://dev.w3.org/2009/dap/vibration/







   [38]: http://dev.w3.org/cvsweb/2009/dap/vibration/Overview.html







   [39]: http://www.w3.org/2009/dap/wiki/ImplementationStatus#Vibration_API







   [40]: http://w3c-test.org/dap/tests/vibration/submissions/robin/







   [41]: http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt







   [42]: http://www.w3.org/2009/dap/track/issues/127/edit







   [43]: https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/battery







   [44]: http://lists.w3.org/Archives/Public/public-device-



apis/2012Oct/0050.html







   [45]: http://www.w3.org/2012/09/26-audio-minutes.html#item05







   [46]: http://www.w3.org/2012/09/26-audio-minutes.html#item05Audio







   [47]: http://welcome.solutions.brother.com/BSC/FAQ_IKOU_IMG/faq000717_000/m



y_comp1.gif







   [48]: http://www.computing-tips.net/img/avacam_webcam.gif







   [49]: http://www.html5rocks.com/en/tutorials/getusermedia/intro/







   [50]: http://supportforums.blackberry.com/t5/image/serverpage/image-



id/10499i92514F6021C56011/image-size/original?v=mpbl-1&px=-1







   [51]: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-



capture-20120712/doc/







   [52]: http://dev.w3.org/2011/webrtc/editor/getusermedia.html







   [53]:



http://www.w3.org/mid/001401cd96e5$7a73f7b0$6f5be710$@murthy@cmcltd.com







   [54]: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html







   [55]: http://w3c-test.org/dap/proximity/tests/submissions/marcos/







   [56]: http://www.w3.org/2012/11/01-dap-minutes.html#action03







   [57]: http://www.w3.org/2012/11/01-dap-minutes.html#action04







   [58]: http://www.w3.org/2012/11/01-dap-minutes.html#action05







   [59]: http://www.w3.org/2009/dap/track/actions/474







   [60]: http://www.w3.org/TR/2011/WD-netinfo-api-20110607/







   [61]: http://lists.whatwg.org/htdig.cgi/whatwg-



whatwg.org/2012-May/036116.html







   [62]: http://docs.phonegap.com/en/edge/cordova_connection_connection.md.htm



l#Connection







   [63]: http://www.w3.org/2012/11/01-dap-minutes.html#action06







   [64]: https://wiki.mozilla.org/WebAPI/WebActivities







   [65]: http://lists.w3.org/Archives/Public/public-web-



intents/2012Jun/0061.html







   [66]:



https://wiki.mozilla.org/WebAPI/WebActivities#Handle_an_activity_request







   [67]: http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html







   [68]: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html







   [69]: http://www.w3.org/TR/2012/WD-gallery-20120712/







   [70]: http://www.w3.org/TR/contacts-api/







   [71]: http://www.w3.org/2012/11/01-dap-minutes.html#action07







   [72]: http://www.w3.org/2012/11/01-dap-minutes.html#action08







   [73]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm







   [74]: http://dev.w3.org/cvsweb/2002/scribe/