07:36:01 RRSAgent has joined #dap 07:36:01 logging to http://www.w3.org/2012/11/01-dap-irc 07:36:03 RRSAgent, make logs world 07:36:03 Zakim has joined #dap 07:36:05 Zakim, this will be DAP 07:36:06 I do not see a conference matching that name scheduled within the next hour, trackbot 07:36:06 Meeting: Device APIs Working Group Teleconference 07:36:06 Date: 01 November 2012 07:36:12 tomoyuki has joined #dap 07:37:16 AnssiK has joined #dap 07:37:34 jsoh has joined #dap 07:37:36 tpacbot has joined #dap 07:40:01 Yoshihiro has joined #dap 07:41:05 jgiraud has joined #dap 07:41:17 present+ jerome_giraud 07:41:29 Hidetoshi has joined #dap 07:42:13 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France 07:42:25 Chair: Frederick_Hirsch 07:42:40 Present+ Anssi_Kostiainen 07:42:48 Present+ Frederick_Hirsch 07:43:50 shunan has joined #dap 07:43:50 Takahiro has joined #dap 07:43:59 Takahiro has left #dap 07:45:30 Yoshihiro has joined #dap 07:45:36 bjkim has joined #dap 07:47:11 noriya_ has joined #DAP 07:47:45 Sylvain_Lalande has joined #dap 07:48:16 a12u has joined #dap 07:49:53 glenn has joined #dap 07:53:04 Topic: Administrative 07:53:36 bryan has joined #dap 07:53:46 kensaku has joined #dap 07:53:54 nwidell has joined #dap 07:53:54 trackbot, RRSAgent 07:53:54 Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help. 07:53:59 present+ Bryan_Sullivan 07:54:01 trackbot, start meeting 07:54:03 RRSAgent, make logs world 07:54:05 Zakim, this will be DAP 07:54:05 I do not see a conference matching that name scheduled within the next hour, trackbot 07:54:06 Meeting: Device APIs Working Group Teleconference 07:54:06 Date: 01 November 2012 07:54:08 scribenick bryan 07:54:12 Shinji has joined #dap 07:54:13 shoko has joined #dap 07:54:13 robint has joined #dap 07:54:16 scribenick: bryan 07:54:21 sakkuru has joined #dap 07:54:22 Milan_Patel has joined #dap 07:54:22 s/Teleconference/F2F 07:54:33 fjh: welcome and logistics 07:54:39 comus has joined #dap 07:54:39 Yoshiharu has joined #dap 07:54:44 fjh: intros 07:54:48 gmandyam has joined #dap 07:54:49 kenji has joined #dap 07:54:56 Claes has joined #dap 07:55:03 Present+ Dominique_Hazael-Massieux 07:55:06 dnkim has joined #DAP 07:55:07 Present+ Claes_Nilsson 07:55:07 Present+ Soonbo_Han 07:55:23 hi I'm chairing, from Nokia, Frederick Hirsch 07:55:23 Present+ Yoshiharu_Dewa 07:55:28 Present+ Geun-Hyung KIm 07:55:29 sato has joined #dap 07:55:41 eduardo_fullea has joined #dap 07:55:43 anssik: from nokia, editing a bunch of specs, been out for a while and will catch up 07:55:48 Present+ Jong Soo Oh 07:56:09 hyun has joined #dap 07:56:18 Present+ JongSoo_Oh 07:56:18 bryan: from AT&T, not editing 07:56:21 jiro has joined #dap 07:56:26 skim has joined #dap 07:57:02 jcdufourd: 07:57:09 giuseppe has joined #dap 07:57:09 Dom: back 07:57:18 Eduardo: from Telefonica 07:57:30 Jungkee: editing Pick Media etc 07:57:36 youenn has joined #dap 07:57:43 Present+ Eduardo_Fullea 07:57:47 Claes: from Sony, editing 07:57:56 jerome giraud: orange 07:58:00 (missing most of them...) 07:58:12 adambe has joined #dap 07:58:23 kensaku 07:58:51 aaa: Toshiba 07:58:53 sato from Sony 07:58:59 Takahiro has joined #dap 07:59:00 bbb: from Sony 07:59:05 kensaku from NTT communications 07:59:10 ccc: also from Sony 07:59:18 jcdufourd has joined #dap 07:59:25 Soonbo Han, LGE 07:59:26 soonbo: from LG, interested in Web Intents 07:59:35 s/ccc:/Yoshiharu Dewa:/ 07:59:37 ddd: also from LG 07:59:40 JongSoo_Oh, LGE 07:59:41 eee: also from LG 07:59:49 fff: from KDDI 07:59:50 Jungkee has joined #dap 07:59:55 Present+ Jungkee_Song 07:59:57 present+ giuseppe 07:59:59 guiseppe: from Opera 08:00:11 s/guiseppe/giuseppe/ 08:00:15 s/bbb:/sato/ 08:00:17 ggg: from Google, WebRTC chair, observer 08:00:28 s/ggg/Harald_Alvestrand/ 08:00:31 hhh: (missed all that) 08:00:37 Donyun_Kim, LG Electronics 08:00:45 iii: from ETRI 08:00:51 Sung Hei Kim from ETRI 08:00:51 jjj: also from ETRI 08:00:59 geunhyung from Mobile Web Forum 08:01:09 fff->Hidetoshi Yokota from KDDI 08:01:12 Giri Mandyam, from Qualcomm Innovation Center 08:01:12 kkk: from (.. Korea) 08:01:13 s/jjj/wook hyun/ 08:01:19 giri: from QiC, member 08:01:20 tomoyuki has joined #dap 08:01:20 Present+ sato 08:01:21 Jungkee Song, Samsung Electronics, working on Pick-*-Intent in the group 08:01:26 nwidell, Niklas Widell, from Ericsson AB 08:01:36 Niklas: from Ericsson 08:01:45 youenn fablet, observer, interested in Web Intent and service discovery 08:01:49 Milan Patel, Huawei 08:01:59 (missed the gentlemen before and after Niklas) 08:02:00 s/soonbo:/shan: Soonbo Han/ 08:02:11 s/kkk/shingak kang/ 08:02:16 (observers) 08:02:22 mounir, Mozilla 08:02:28 Present+ Mounir_Lamouri 08:02:45 Present+ noriya sakamoto from toshiba 08:02:57 Present+ Niklas_Widell 08:03:29 darobin has joined #dap 08:05:08 fjh: agenda 08:06:00 hta has joined #dap 08:06:01 Topic: Agenda Review 08:06:10 JonathanJ1 has joined #DAP 08:06:21 richt has joined #dap 08:06:37 fwtnb_ has joined #dap 08:06:41 Present+ Tomoyuki_Shimizu 08:06:48 ... goal is to advance the specs, these first are in good shape 08:06:52 -> http://www.w3.org/2009/dap/ DAP WG home page 08:07:03 richt_ has joined #dap 08:07:11 ... battery spec is in cr, when to goto rec and get testing started is the question 08:07:33 ... ambient light and proximity seem stable, the question is whether we can get to last call 08:07:46 seo has joined #dap 08:07:55 Present+ Rich_Tibbett 08:07:55 daniel_samsung has joined #dap 08:08:03 kotakagi has joined #dap 08:08:12 ... vibration is in cr, need to assess test case status and when we can progress it 08:08:28 ... in summary to figure out roadmap for specs in good shape 08:08:40 ... may also talk about network info api (maybe shelved) 08:09:09 ... also privacy in general, in principle, christine sharing the privacy group may join us 08:09:35 ... we kind of pushed the earlier work aside and focused on data minimization, but need to consider revisiting 08:09:44 adrianba has joined #dap 08:09:49 ... we may take longer breaks for discussions 08:10:12 ... after break html media capture, in LC and stable but has some comments recently 08:10:37 ... we got lc comments, and some responses were not accepted. we need to resolve all today to proceed to LC 08:10:56 ... after lunch, web intents all afternoon 08:11:41 ... need to review webapps discussion, and discuss status and implementations, issues etc from google 08:12:01 Wonsuk has joined #dap 08:12:20 ... mounir also is here and we need to take these two pieces of work forward 08:12:25 Present- Tomoyuki_Shimizu 08:12:27 Present+ Jonathan_Jeon 08:12:28 ... tomorrow we will start at nine 08:12:30 Present+ Wonsuk_Lee 08:12:57 ... tomorrow on the specs built upon web intents, including calendar to get it moving again 08:13:12 npdoty has joined #dap 08:13:31 ... then claes's work on web intents addendum. cathy is not here (Sandy) but we need to discuss the comments 08:13:50 claes: there were breakout sessions and will share results 08:14:12 sakkuru has joined #dap 08:14:13 fjh: after lunch richt's network service discovery draft 08:14:23 Josh_Soref has joined #dap 08:14:23 seo has joined #dap 08:14:29 ... somewhere about media capture and streams 08:14:33 whyun has joined #dap 08:14:45 ... hopefully travis will be here to talk about tracks 08:15:07 ... then something about billboards, (digital signage) 08:15:44 ... maybe talking about coremob what to do with them 08:15:56 ... on interop, a lot of work being done on testing and tools 08:16:15 ... been working on the actions and not much to do there 08:16:25 ... rough outline so far, anything else? 08:16:35 q? 08:16:35 q? 08:17:02 Topic: Minutes approval 08:17:09 ... any objection to approving the minutes 08:17:18 RRSAgent, draft minutes 08:17:18 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:17:34 RRSAgent, make logs public 08:17:35 RRSAgent, draft minutes 08:17:35 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:17:46 proposed RESOLUTION: Minutes from 3 October 2012 are approved. 08:17:48 s/trackbot, RRSAgent// 08:17:55 RESOLUTION: Minutes from 3 October 2012 are approved. 08:17:55 s|Sorry, dom, I don't understand 'trackbot, RRSAgent'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.|| 08:18:01 s/scribenick bryan// 08:18:04 bryan: what about sysapps 08:18:38 ... would like to talk about synergy 08:18:38 s/Yoshiharu Dewa:/Yoshiharu_Dewa:/ 08:18:51 s/wook hyun:/wook_hyun:/ 08:18:59 http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/att-0014/minutes-2012-10-03.html 08:19:01 s/shingak kang:/shingak_kang:/ 08:19:07 Topic: Relationships with SysApps WG 08:19:15 s/giri:/gmandyam:/ 08:19:18 RRSAgent, draft minutes 08:19:18 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:19:29 s/Niklas:/Claes:/ 08:20:11 s/sato from Sony/sato: Sato, Sony/ 08:20:13 s/sato from Sony// 08:20:34 Yuan has joined #dap 08:20:39 bryan: would like to have synergy with DAP, and share common privacy approaches for example 08:20:39 s/Yoshiharu_Dewa:/Yoshiharu_Dewa: Yoshiharu Dewa, Sony/ 08:20:49 bryan: would like to look at privacy more closely 08:21:07 dom: how can we be concrete on this 08:21:16 s/giuseppe:/giuseppe: Giuseppe Pascale/ 08:21:18 sunghan has joined #dap 08:21:27 bryan: might consider extending existing DAP interfaces in sysapps 08:21:37 s/Harald_Alvestrand: from Google/Harald_Alvestrand: Harald Alvestrand, Google/ 08:22:10 richt: if it can run in the browser context it should be defined in DAP 08:22:24 s/fff: from KDDI/Hidetoshi: Hidetoshi Yokota from KDDI/ 08:22:35 s/fff->Hidetoshi Yokota from KDDI// 08:22:46 overlap of dap and sysapps is about five people 08:22:57 at least hands raised in the room 08:23:33 jcdofourd: some apis picked up in sysapps have been shelved in this group, it should not be forbidden in another 08:24:02 fjh: we need to be productive, and ensure that browser context use is in the specs that browser vendors will implement 08:24:08 s/Claes: from Sony, editing/nwidell: Niklas Widell from Sony, editing/ 08:24:17 ... maybe it would make sense to see how it plays out, but not get into it deep now 08:24:32 RRSAgent, draft minutes 08:24:32 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:24:47 jcdofourd: execution and security model is a worse overlap, a meta-level for interfaces 08:24:50 -> https://www.w3.org/2000/09/dbwg/overlap?ids[43696]=on&ids[58119]=on Overlap of formal participants between DAP and SysApps WG 08:25:06 ... how things should work around security 08:25:07 waynecarr has joined #dap 08:25:17 fjh: in other words we should look at it 08:25:18 waynecarr has left #dap 08:25:34 ... there was a contribution in sysapps 08:25:45 s/nwidell: Niklas Widell from Sony, editing/Claes: Claes Nilsson from Sony, editing/ 08:25:54 jcdufourd: (there are some proposals) 08:26:18 ISSUE: should DAP review and take advantage of SysApps security models 08:26:18 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 . 08:26:32 s/Claes: from Ericsson/nwidell: Niklas Widell, from Ericsson/ 08:26:37 q+ 08:26:43 RRSAgent, draft minutes 08:26:43 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:26:44 Kangchan has joined #dap 08:26:45 tpacbot has joined #dap 08:26:52 fjh: concerned about two working groups with different IPR etc not sure what we can do here 08:26:57 ack nwidell 08:27:30 tomoyuki has joined #dap 08:27:31 nwidell: when the charter was discussed, the sysapps APIs were intended to have a flexible security model 08:27:31 -> http://www.w3.org/2012/09/sysapps-wg-charter SysApps WG charter 08:27:51 topic: battery api 08:27:54 skang5 has joined #dap 08:28:06 anssik: 08:28:29 anssik: brief overview of battery status api 08:28:51 s/jcdufourd:/jcdufourd: Xjcdufourd/ 08:28:54 RRSAgent, draft minutes 08:28:54 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:29:09 anssik: various features exposed for implementation in browsers and web-based os's... works in both world 08:29:23 s/jcdufourd: Xjcdufourd/jcdufourXd: Xjcdufourd/ 08:29:24 q+ 08:29:27 s/jcdufourd:/jcdufourd: Xjcdufourd/ 08:29:33 anssik: sitting in cr for a while. no CRs since then, so the spec is considered stable 08:29:42 s/jcdufourXd: jcdufourd/jcdufourd: / 08:29:43 q? 08:29:46 RRSAgent, draft minutes 08:29:46 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:29:50 spoussa has joined #dap 08:29:54 anssik: currently a stable version in firefox nightly 08:30:12 Milan_Patel has joined #dap 08:30:13 anssik: backends are available for windows 08:30:17 s|s/jcdufourXd: jcdufourd/jcdufourd: /|| 08:30:26 s/jcdufourXd: Xjcdufourd/jcdufourd: / 08:30:28 -> http://w3c-test.org/dap/battery/tests/ Battery API test suites 08:30:29 RRSAgent, draft minutes 08:30:29 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:30:35 anssik: been working on a test suite, just run the suite and provide feedback 08:30:36 s/suites/suite 08:30:53 ... it's a bit tricky since automated tests are not possible or easy 08:31:06 ... part of the tests address interfaces and others are manual tests 08:31:15 q+ to ask about (other) implementation plans, idlharness 08:31:16 ... results are manually validated 08:31:17 s/Xjcdufourd/Jean-Claude Dufourd/ 08:31:22 RRSAgent, draft minutes 08:31:22 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:31:29 q+ to ask about testing methodology in DAP general 08:31:34 ... next steps after validation of the suites, moving to PR 08:31:40 Present+ Sakari_Poussa 08:31:52 ack richt 08:31:57 SKim has joined #dap 08:32:07 s/Dom: back/dom: Dominique Hazael-Massieux, w3/ 08:32:16 richt: we dont have to rush to PR 08:32:27 ... what were the implementations so far? 08:32:54 anssi: firefox (browser and OS), tizen 2.0 08:32:57 -> http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API Implementation status of battery API 08:33:05 s/Present+ noriya sakamoto from toshiba/Present+ Noriya_Sakamoto/ 08:33:06 richt: has this seen any adoption and interesting use cases? 08:33:28 s/Present+ Geun-Hyung KIm/Present+ Geun-Hyung_KIm/ 08:33:30 anssik: developers seem excited at conferences 08:33:37 s/Present+ Jong Soo Oh/Present+ Jong_Soo_Oh/ 08:33:54 ... when you combine this with some other APIs more cool stuff is expected 08:33:54 * spec in CR since May 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html 08:33:58 RRSAgent, draft minutes 08:33:58 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:34:06 * no normative changes since CR, spec changelog: http://dvcs.w3.org/hg/dap/log/tip/battery/Overview.html 08:34:10 present+ Josh_Soref 08:34:15 fjh: we need to ensure its done right and do not want to rush, but move forward 08:34:20 * implementation status: Firefox (Nightly), Firefox OS, some WebKit ports (such as EFLWebKit): http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API 08:34:26 richt: the objective is lots of implementations, not just a spec 08:34:34 * try it on Firefox Nightly (will ship in Firefox 18 unprefixed?): http://nightly.mozilla.org/ 08:34:42 s/Donyun_Kim/Donyun Kim/ 08:34:45 * test suite, reviews appreciated: http://w3c-test.org/dap/battery/tests/submissions/anssik/ 08:34:46 present+ Donyun_Kim 08:34:50 * battery-interface.html is the only fully automated test, others are functional tests 08:34:53 ... we have hints that clarifications may be needed, maybe leave in CR for a couple or years as we work them out 08:34:54 q? 08:34:55 * next: move to PR? 08:34:57 ack dom 08:34:57 dom, you wanted to ask about (other) implementation plans, idlharness and to ask about testing methodology in DAP general 08:34:59 fjh: not sure that is a good idea 08:35:08 [that was an outline of my talk] 08:35:17 +q 08:35:28 dom: so to recap, just mozilla as a browser today. not sure we should move to CR with just one browser implementing 08:35:32 s/Present+ sato/Present+ Naoyuki_Sato/ 08:35:37 s/CR/PR/ 08:35:42 ... any comments from the room? 08:35:47 Takahiro has joined #dap 08:35:58 present+ Sylvain_Lalande 08:36:14 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. 08:36:27 mounir: its in firefox 16 08:36:42 anssik: will try to provide a live demo 08:37:10 richt: at a design level, its good and on the roadmap with other sensors, competing with other work 08:37:24 ... we agree with the approach and the design though 08:38:08 dom: any other implementation plans to share 08:38:31 yungkee: implementation in tizen is complete 08:38:39 present+ Kensaku_Komatsu 08:38:59 s/kensaku from/Kensaku Komatsu from/ 08:39:19 fjh: answer is firefox and tizen implementations so far 08:39:27 s/kensaku/X_X_X 08:39:28 dom: tizen is not a browser 08:39:56 RRSAgent, draft minutes 08:39:56 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:39:58 anssik: firefox OS and browser are different too 08:40:15 s/kensaku// 08:40:22 dom: important to stick to browsers as the goal for implementations 08:40:24 s/X_X_X/kensaku/ 08:40:29 RRSAgent, draft minutes 08:40:29 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:40:38 anssik: how much platform-specific code is in tizen? 08:40:55 yungkee: will follow up to see what can be shared 08:41:14 robint has joined #dap 08:41:25 wonsuk: heard about a blackberry implementation 08:41:40 s/yungkee/jungkee/ 08:42:32 anssik: (shows a demo of tests) 08:42:35 s/kensaku/scribe/ 08:42:51 RRSAgent, draft minutes 08:42:51 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:43:02 ... just looking at the interface as specified, easy stuff 08:43:08 s/Kensaku Komatsu/kensaku: Kensaku Komatsu/ 08:43:10 RRSAgent, draft minutes 08:43:10 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:43:24 q+ to mention idlharnes 08:43:53 s/dnkim/scribe/ 08:43:55 s/Donyun Kim/dnkim: Donyun Kim/ 08:44:33 ... (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 08:44:58 s/skim/scribe/ 08:45:11 s/Sung Hei Kim/SKim: Sung Hei Kim/ 08:45:13 ... calculation is in the web worker, waiting for the discharging time to update... this shows how testing this type of API can be challenging 08:45:33 ... maybe webdriver could help, so to emulate some operations 08:45:54 ... the test was passed 08:46:14 ... after running you have to validate by checking the system battery against what was reported 08:46:31 s/jsoh/scribe/ 08:46:40 s/JongSoo_Oh, LGE/jsoh: JongSoo_Oh, LGE/ 08:46:44 RRSAgent, draft minutes 08:46:44 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 08:46:49 ... 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 08:47:13 q? 08:47:19 ... deciding when to prompt the user is tricky 08:47:29 richt: probably should not mark as passed 08:47:38 GregBillock has joined #dap 08:47:57 anssik: got the language from the css reftests, to prompt the user on what is expected 08:48:18 present+ Jean-Claude_Dufourd 08:48:22 richt: in css tests you have visual feedback and also programmatic checking 08:48:42 dom: not sure the harness has this yet, but in this case it's a pass but check result 08:49:00 ... someone needs to bring the idea to the public testing list 08:49:05 s/youenn fablet/Youenn Fablet/ 08:49:08 q? 08:49:11 s/youenn/scribe/ 08:49:17 anssik: so the harness API does not support 08:49:24 s/Youenn Fablet/youenn: Youenn Fablet/ 08:49:24 dom: not sure 08:49:29 q+ 08:49:39 present+ Jinhong_Yong 08:49:50 present+ Giri_Mandyam 08:50:13 s/+q/q+/ 08:50:17 dom: one of the difficulties is testing the API itself and also how it is developed in an implementation 08:50:35 jungkee: haven't tried this test yet (richt asked) 08:50:48 ack gmandyam 08:51:18 spoussa has joined #dap 08:51:21 giri: these are assert tests 08:51:53 gmandyam: until you have fully charged the battery you can't verify the implementation 08:52:17 AnssiK: re: my question to Jungkee. Tests are very new (1 day old) so they have not been run against the Tizen impl yet. 08:52:18 fjh: what I heard is that the test that matters are fully charging and discharging? 08:52:33 SungOk_You has joined #dap 08:52:47 gmandyam: time to discharge test requires a full discharge to verify 08:53:12 anssik: what you cant do in automated tests is determine if the reported value is the actual value 08:53:25 ... you have to check with other data e.g. at the OS level 08:54:02 gmandyam: have compared whats in the OS vs what's in javascript, and found differences... should we consider that in the tests? 08:54:18 q+ 08:54:35 is that difference a rounding error gmandyam, or something more serious? 08:54:35 anssik: it's up to the glue layer to define any translations exposed to the browser 08:55:10 gmandyam: can we really say an implementation is compliant, it the reading varies from the OS? 08:55:31 richt: is this a rounding error or a bigger difference? 08:55:40 Daniel_Samsung has joined #Dap 08:56:23 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 08:57:33 q? 08:57:36 ack dom 08:57:36 dom, you wanted to mention idlharnes 08:57:38 mounir: we use the exact value that the OS tells you (thru the API), to avoid fingerprinting we take steps 08:57:38 shan has joined #dap 08:58:27 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 08:58:29 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) 08:59:07 ... also how much linking test cases with assertions so far? 08:59:21 q? 08:59:23 anssik: about 90% 08:59:46 RRSAgent, draft minutes 08:59:46 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:00:43 ... looking at the spec (highlighting how paragraphs map to tests), its not so easy to separate tests back to prose 09:00:59 dom: and thanks for getting these tests done 09:01:07 ack mounir 09:01:08 ack 09:01:13 anssik: it's been good to work with mounir, a good collaboration 09:01:21 mounir: to report the issues we have found 09:02:04 present+ Shin-Gak_Kang 09:02:14 ... it's hard to test this in hardware, so we are using emulators 09:02:35 ... so we change the value in the emulator and verify the change thru the API 09:02:57 ... every platform has different implementations, we have found bugs in different OS 09:03:08 present+ Wook_Hyun 09:03:15 ... it's not as easy to check any version to see if it's conforming 09:03:18 q? 09:03:22 ack Josh_Soref 09:04:04 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 09:04:25 ... some divergence is acceptable between the system and user perception 09:04:41 q? 09:04:45 q+ 09:04:47 ... that this is different from some other estimate that is questionable is not a valid concern 09:04:59 ack richt 09:05:25 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 09:05:27 q+ 09:05:45 ... so I can test if the feature is supported thru the API? 09:05:59 mounir: (responds) 09:06:02 mounir: the spec defines default values 09:06:10 present+ Sung_Hei_Kim 09:06:20 mounir: we return those default values if we don't have the backend implemented for the platform 09:06:24 present+ Juan_Ji 09:06:39 anssik: if you expose the object but don't have the implementation, we test for that, to avoid fingerprinting via a dummy interface 09:06:39 s/mounir:/mo_unir:/ 09:06:43 s/mounir/scribe/ 09:06:45 q? 09:06:49 s/mo_unir:/mounir:/ 09:06:54 ack 09:06:56 RRSAgent, draft minutes 09:06:56 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:06:57 q? 09:06:59 q- 09:07:09 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 09:07:09 ack gmandyam 09:07:19 Milan_Patel has joined #dap 09:07:23 gmandyam: based upon the mobile perspective, we're trying to get developers aware of battery state 09:07:44 ... the level is clearly an estimate, but consistency with the OS is important 09:07:45 shunan has joined #dap 09:07:51 q+ 09:07:59 … as well as this one: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-interface.html 09:08:09 ... I tested the mozilla implementation as input to a paper for the web performance workshop next week 09:08:28 seo has joined #dap 09:08:48 ... when I discharged the battery all the way, there was a clear discrepancy in the javascript (20-30%) 09:08:53 [the first test is useful *only* if there's no backend impl] 09:09:04 q? 09:09:14 Josh_Soref: that's the type of bug we need to see reported 09:09:23 gmandyam: on which platform? 09:09:23 fjh: so next steps with this work 09:09:24 ackfjh 09:09:28 a/ackfjh// 09:09:30 q? 09:09:33 ack fjh 09:09:45 s/reported/reported (it's ok, for the UA battery report to indicate dying sooner, but not ok to report dying after the OS)/ 09:09:54 anssik: will continue on the tests, will test tizen devices when available (also firefox OS, please provide one!) 09:10:08 ... about the next process step 09:10:51 richt: before we have finished specs, and shelved with no implementations. we should expect some inertia now, and some time before wider implementations 09:11:20 RRSAgent, draft minutes 09:11:20 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:11:22 ... its not a huge concern to get to PR, but we cant progress at this point though the spec is still alive 09:11:42 fjh has changed the topic to: dap 3279 ; http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France 09:11:42 anssik: IP committments kick in so we need to get there asap 09:11:59 dom: until we get another browser implementation the question is pretty moot 09:12:07 action: dom to review Battery test and contribute more tests 09:12:07 Created ACTION-585 - Review Battery test and contribute more tests [on Dominique Hazaël-Massieux - due 2012-11-08]. 09:12:33 anssik: would be better if someone else also contributes tests 09:12:53 richt: lack of implementation does not imply disagreement (want to make that key point) 09:12:55 RRSAgent, draft minutes 09:12:55 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:13:09 s/kick in/kick in in REC/ 09:13:11 s|a/ackfjh//|| 09:13:18 s|ackfjh|| 09:13:27 RRSAgent, draft minutes 09:13:27 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:13:37 dom: we have made a call for implementations, otherwise the spec is ready 09:14:15 richt: there doesn't seem to be disagreement, just not clear and broad agreement 09:14:34 dom: one open question, what is the process for approving test suites 09:14:49 ... by default, by review, etc 09:15:19 ... the default is that they are approved until problems are found 09:15:33 richt: think we should have a code review 09:15:43 ... W3C should have such systems in place 09:15:53 action: richt to review Battery tests 09:15:54 Created ACTION-586 - Review Battery tests [on Richard Tibbett - due 2012-11-08]. 09:16:09 JonathanJ1 has joined #DAP 09:17:34 topic: Vibration API 09:17:46 s|heard about a blackberry implementation|-> https://developer.blackberry.com/html5/apis/blackberry.system.html#.event:batterystatus "BlackBerry 10" implementation| 09:17:49 anssik: spec is in CR since may 09:17:52 RRSAgent, draft minutes 09:17:52 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 09:18:15 nwidell has joined #dap 09:18:20 ... minor clarifications, implemented in firefox OS, tizen. test suite draft by robin 09:19:00 mounir: also firefox android 09:19:14 * spec in CR since May 2012: http://dev.w3.org/2009/dap/vibration/ 09:19:30 * minor clarifications since CR, changelog: http://dev.w3.org/cvsweb/2009/dap/vibration/Overview.html 09:19:40 anssik: its exposed to the browser but if it doesn't have the hardware it won't do anything 09:19:45 q? 09:19:55 * implementation status: Firefox, Firefox for Android, Firefox OS, WebKit: http://www.w3.org/2009/dap/wiki/ImplementationStatus#Vibration_API 09:20:08 * test suite draft by darobin: http://w3c-test.org/dap/tests/vibration/submissions/robin/ 09:20:28 * test suite TODOs: http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt 09:20:35 * next: work on the test suite 09:20:40 wonsuk: clarifying, wekbit supports many browsers based upon linux (a lot of ports) 09:21:18 s/Juan_J/Yuan_J/ 09:21:19 ... the EFL port has many browsers in testing. this may be helpful to CR? 09:21:31 ... (this was related to the battery API, not Vibration) 09:22:00 ... Tizen is a Web-based OS, but provides different context (system app and browser) 09:22:40 ... we can provide test results based upon tizen for our target devices. will that be helpful to move to CR for the battery API? 09:22:43 giuseppe has joined #dap 09:23:21 fjh: will the open-source status of the browser should help (this is the question) 09:23:42 noriya has joined #DAP 09:23:44 dom: is it a shipping browser that has battery, or an experiment 09:24:10 wonsuk: its testable in a test environment based upon the EFL port 09:24:26 dom: what we want is real browsers that are shipping 09:24:39 richt: 2 is the minimum 09:25:08 bryan: does browser implementation mean installable on any platform? 09:25:28 josh: apis for general web apps for general browsers in general deployments 09:25:40 josh: test implementation not suitable for exiting C 09:25:43 s/C/CR/ 09:26:03 josh_soref: the browser needs to be a major browser, not puppet implementations 09:26:07 s/shipping/shipping to leave CR/ 09:26:45 need to clarify in battery API status that exit criterial for CR is 2 independent real world browsers 09:26:49 dom: technically we need to have two implementations, two real-world implementations independently sourced 09:26:51 s/josh:/Josh_Soref:/G 09:26:55 s/josh_soref:/Josh_Soref:/G 09:27:44 Daniel has joined #Dap 09:27:58 ISSUE: status section of Battery CR draft should include exit criteria and at-risk items 09:27:59 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 . 09:28:17 bryan: we are expecting real world implementations expected for wide use, not just the "big five" 09:28:59 re: battery implementation in webkit, see https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/battery 09:29:22 (I don't see it is enabled by any webkit-based browser currently.) 09:29:38 dom: we need an exit criteria (not necessarily well-defined), and the director will make a decision whether we have really met the criteria 09:31:14 nkic has joined #dap 09:56:20 a1zu has joined #dap 09:58:31 kotakagi has joined #dap 10:00:07 RRSAgent, draft minutes 10:00:07 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html shan 10:02:07 nwidell has joined #dap 10:02:30 Hidetoshi has joined #dap 10:03:45 kenji has joined #dap 10:05:02 adrianba has joined #dap 10:05:10 giuseppe has joined #dap 10:06:26 comus has left #dap 10:06:44 darobin has joined #dap 10:06:49 smaug has joined #dap 10:07:41 Geun_hyung has joined #dap 10:08:11 present+ Geun-Hyung_Kim 10:08:51 a12u has joined #dap 10:09:10 nwidell has joined #dap 10:10:02 spoussa has joined #dap 10:12:08 topic: HTML Media Capture 10:12:18 fjh: we have a LCWD with some feedback 10:12:24 npdoty has joined #dap 10:14:15 shoko_ has joined #dap 10:14:17 general comment on HTML Media Capture comment http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/0050.html 10:14:17 jfmoy has joined #dap 10:14:35 shepazu is here 10:14:35 youenn has joined #dap 10:14:35 jgiraud has joined #dap 10:15:02 GregBillock has joined #dap 10:15:10 fjh: thought about comments of doug 10:15:24 ... e.g. might want mic vs video, different use cases 10:15:32 Wonsuk has joined #dap 10:15:33 jiro has joined #dap 10:15:40 ... other comments about front vs back and selection 10:15:48 bjkim has joined #dap 10:16:13 ... other work in media capture, with streams and tracks etc... this seems related to the goals 10:16:16 jcdufourd has joined #dap 10:16:34 ... maybe that's the solution, and it shouldn't be in html media capture 10:16:43 bryan: +1 to reuse 10:16:57 shepazu has joined #dap 10:17:15 fjh: mime types dont seem to relate to the track objectives etc... what problems are we trying to solve? 10:17:33 shepazu: comments are more about setting correct usability and privacy expectations 10:18:00 ... e.g. get camcorder. does that necessarily include audio, is video recording automatically include audio? 10:18:23 anssik: think that users will expect what the native platform would provde 10:18:41 ... that is an implementation concern 10:18:49 present+ Doug_Schepers_(shepazu) 10:18:55 q+ 10:19:04 dom: to be clear, the html media capture is a shortcut to enable recording 10:19:19 Yuan has joined #dap 10:19:22 ... giving direct access to the native application through a button for example 10:19:54 ... the user doesn't have to 1st record and then upload. but it still uses the basic OS framework, and nothing extra 10:20:08 ... the media capture API will provide that 10:20:15 q+ olivier 10:20:20 fjh: we need an intro section setting expectations 10:20:28 ack fjh 10:20:36 q? 10:20:37 shepazu: the rewrite should address the relationship with getusermedia 10:20:45 sunghan has joined #dap 10:20:53 fjh: agree we have a spec that is unclear per the landscape 10:21:19 shepazu: need to clarify that "camcorder" includes audio. that needs to be clear. 10:21:32 dom: again camcorder only starts the native application 10:21:41 kensaku has joined #dap 10:21:46 shepazu: in that case the author needs to know if they will get audio 10:21:51 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 10:22:09 clarify as Dom mentioned that is shortcut for file upload 10:22:14 dom: the application just hands the user to the native feature 10:22:15 s/fjh/scribe/ 10:22:16 s/fjh/scribe/ 10:22:25 s/I propose/fjh: I propose/ 10:22:26 http://www.w3.org/2012/09/26-audio-minutes.html#item05 10:22:35 s/clarify/fjh: clarify/ 10:22:42 RRSAgent, draft minutes 10:22:42 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 10:22:43 ... normal operations result and when coming back to the app, the user will find the file and then upload etc 10:22:56 shepazu: upload what, does it include audio? 10:23:09 ack olivier 10:23:12 dom: if you need more control from the app, you need to use getusermedia 10:23:16 q+ 10:23:47 Audio WG concerns with HTML Media Capture API -> http://www.w3.org/2012/09/26-audio-minutes.html#item05 10:24:08 olivier: there are different perspectives on what features are involved here, but it doesn't sound future proof 10:24:11 s|Audio WG concerns with HTML Media Capture API -> http://www.w3.org/2012/09/26-audio-minutes.html#item05|-> http://www.w3.org/2012/09/26-audio-minutes.html#item05 Audio WG concerns with HTML Media Capture API| 10:24:18 RRSAgent, draft minutes 10:24:18 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 10:24:32 ... we are talking about images, audio, and video, not just what devices give you those 10:24:53 ... from the audio WG we are worried that there are two APIs providing the same things 10:25:06 anssik: we do need to clarify the keywords 10:25:22 ... e.g. capture is "still image capture device" 10:25:31 s/capture/camera/ 10:25:33 noriya has joined #DAP 10:25:48 ... and camcorder is a "motion capture device" 10:26:16 shepazu: is this the wording or the keywords that are proposed to be changed? 10:26:42 ... motion capture can be haptic etc, would suggest to use "video" 10:26:56 fjh: how real an issue is "camcorder" vs video? 10:27:08 olivier: the concern is more about consistency 10:27:26 shepazu: camcorder is an old term 10:28:13 josh_soref: (proposes an experiment) 10:28:36 s/experiment -- and it fails -- miserably/ 10:28:44 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 10:29:17 ... more generally, we have a "accept" attribute that enables selection of the type of file to get 10:29:22 q+ to say that the option thing is silly since, ideally the UA will just do this automatically 10:29:30 kotakagi has joined #dap 10:29:48 ... what ends up is a launch with filtering of the selected tools 10:30:03 ... it's fine the way it is 10:30:11 YOshihiro has joined #dap 10:30:46 Yoshihiro has joined #dap 10:30:54 shepazu: agree that there is a place for this, it addresses use cases getusermedia does not 10:30:58 q+ 10:31:13 a12u has joined #dap 10:31:26 ... we need more explanation of how HTML is being extended, and that expectations for the author and user are not being clarified 10:31:52 ... don't want the author to guess what the app will offer to the user 10:32:13 fjh: we got a comment that we need more clear text 10:32:16 ack fjh 10:32:38 anssik: we do need to more clearly describe how the options address the different use cases 10:32:53 shepazu: that would help, for that part of it 10:33:27 fjh: so there is not enough info for a first time reader to understand, and we need to improve that 10:33:59 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 10:34:23 fjh: we need to say something related to the content in the file (audio vs video) 10:34:57 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 10:35:09 ... you get just the ability to select a file type 10:35:35 shepazu: it's not just the file. you are interacting with the application, e.g. a video camera, not a file type 10:35:55 dom: we are not getting a camera, but the file object 10:36:04 jinhong has joined #dap 10:36:14 ... what does is saying is that informative language update may not be enough 10:36:31 -> http://welcome.solutions.brother.com/BSC/FAQ_IKOU_IMG/faq000717_000/my_comp1.gif file picker with scanner 10:36:42 q- 10:36:46 ... once you have the file, the app may be able guide the user to do something different as needed by the app 10:36:55 q+ 10:36:58 ack josh_soref 10:36:58 Josh_Soref, you wanted to say that the option thing is silly since, ideally the UA will just do this automatically 10:37:06 kinji has joined #dap 10:37:06 ... if the app needs more control, then it needs to use getusermedia 10:37:22 josh_soref: dropped in picture links 10:37:22 -> http://www.computing-tips.net/img/avacam_webcam.gif file picker with cameraq 10:37:40 q? 10:38:07 ... want to note that people used to think of windows explorer as a file picker 10:38:36 ... this is now false, the picker can show other things as virtual files e.g. a scanner 10:39:20 ... the picker can offering ways to get data of a source, that could include hints to the user 10:39:41 ... the user can select different sources of the same type, e.g. an image or a camera 10:40:18 ... but in the end it's just a file that is being selected. if more is needed the app should use getusermedia 10:40:45 q? 10:40:47 ack gmandyam 10:41:08 s/cameraq/camera/ 10:41:27 gmandyam: a broader perspective, prior to joining the DAP WG, ... 10:41:44 ... I heard two arguments in favor of html media capture 10:42:06 ... the first is a bogus argument, don't see the value in adding a new DOM element just for capture 10:42:23 ... also the argument over the privacy approach is bogus 10:42:23 q+ 10:42:54 q+ richt 10:43:03 ... even though getusermedia is still being developed, we can expect that a dialog box will provide the user with options also 10:43:07 q+ 10:43:10 youenn has joined #dap 10:43:26 ... in the next few months we will have similar and better capabilities with getusermedia 10:43:31 ack dom 10:44:03 dom: responding, was at the mediacapture TF meeting, and its optimistic that in 6 mos we will have a stable spec 10:44:05 Josh_Soref: +1 (i minuted) 10:44:09 s/its/it's/ 10:44:37 ... 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 10:45:01 RRSAgent, draft miinutes 10:45:01 I'm logging. I don't understand 'draft miinutes', Josh_Soref. Try /msg RRSAgent help 10:45:02 ... a simple declarative way to get a picture without dependency upon detailed features 10:45:03 RRSAgent, draft minutes 10:45:03 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 10:45:10 +1 to having simple interface for functionality in addition to getusermedia that offers more control 10:45:24 ... coremob also has identified the use cases of getting a picture as important 10:45:52 gmandyam: expect javascript libraries to extract away the complexity for those apps that need just a simple picture capture 10:46:44 ack richt 10:46:50 dom: agree libraries can also get the same output, but the library can't expose things equivalent to the default UI of the device 10:47:20 RRSAgent, draft minutes 10:47:20 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 10:47:23 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 10:47:43 ... this is not about control over the file, just selection 10:47:49 q? 10:48:00 ... making it easier for the users to get to the file (type) they want to share 10:48:04 q+ 10:48:08 q+ 10:48:14 "a quicker picker" 10:48:19 ... purely innovation at the file picker level 10:48:29 q+ to support the use cases for this spec 10:48:37 ack AnssiK 10:48:37 anssik: love getusermedia, great for its use cases 10:49:11 GregBillock has joined #dap 10:49:11 ... 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 10:49:28 nkic has joined #dap 10:49:57 ... additional point for doug, about privacy/security. if an app wants audio + video, but I don't want audio just the video, ... 10:50:11 ... i need the freedom to get the video without the audio 10:50:44 ack fjh 10:50:56 shepazu: you should be able to express what you want, and the user should be able to modify that 10:51:27 q? 10:51:29 q+ 10:51:33 ... saying accept to one file type, doesn't necessarily imply both types of content are acceptable 10:52:10 ... want the user to know what the app's expectation is, and to give the user the option to choose 10:52:38 dom: html can be used to express to the user what the app expects, before they click the button 10:53:16 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/ 10:53:17 richt: understand the intent, that user opt-in to audio is important 10:53:49 ... that's not a feature of the native application, to offer that control by an API of the platform 10:54:36 kinji has joined #dap 10:54:36 shepazu: when you popup the dialog, you chrome can't popup something that clarifies what is asked for? 10:54:39 a12u has joined #dap 10:55:15 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 10:55:35 shepazu: you can ask it, whether it listens is another matter 10:56:16 olivier: at the moment you can, but specifying it is a start and will promote development of the native APIs 10:56:17 q+ 10:56:28 q- 10:56:35 ack shepazu 10:56:35 shepazu, you wanted to support the use cases for this spec 10:56:38 q+ 10:56:44 q- 10:56:48 shepazu: those who are developing platforms are in control, and can develop this. we just need to make it possible thru the spec 10:57:13 ... the audio WG wants the html media capture spec, to get to market quickly. 10:57:32 ... getusermedia will take longer, and in the meantime this is critically important 10:57:35 q+ 10:57:44 ... really support the spec, but want it to be done right 10:58:07 dom: the only thing not possible is to enable recording of video only? 10:58:17 ... to separate the video and audio? 10:58:31 ... what is the use case, when would you want that? 10:58:46 Wonsuk has joined #dap 10:59:02 q? 10:59:03 shepazu: if you want videos, but have privacy concern about the collection of an audio track 10:59:39 richt: we could put that in the dialog, and hand off to the native app, then strip the audio out 10:59:45 q+ to say that if we offer this stripping and fail to do it, there's probably more liability 10:59:46 there are some legal jurisdictions where recording audio requires a higher legal bar than capturing video, fwiw 10:59:53 shepazu: not asking for that, just to inform the user 11:00:06 ack me 11:00:06 AnssiK has left #dap 11:00:33 AnssiK has joined #dap 11:00:51 fjh: would it help to have keywords to allow the separate source types to be included 11:01:01 noriya has joined #DAP 11:01:29 shepazu: more keywords seems more complex... my solution is to have a list of what is requested 11:01:54 fjh: so what olivier is requesting is that we think ahead 11:03:04 s/and hand off to the native app, then strip the audio out/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./ 11:03:12 -> http://supportforums.blackberry.com/t5/image/serverpage/image-id/10499i92514F6021C56011/image-size/original?v=mpbl-1&px=-1 BlackBerry File Picker with Camera 11:03:18 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? 11:04:14 q? 11:04:20 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 11:04:21 ack gmandyam 11:05:21 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 11:05:40 richt: getusermedia is about staying in the browser and getting the media 11:06:04 ... this otoh is about switching to the native app seamlessly 11:06:05 q? 11:06:17 olivier1 has joined #dap 11:06:30 ... they are different use cases and both needed. there is no choice between these, they are both important 11:07:00 +1 for richt 11:07:08 fjh: suggest we get to the LC concerns and address them well 11:07:29 LC comments: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/ 11:07:42 ... it would be useful to look at the LC comments each to see if something has been missed, or is it this one issue? 11:07:50 rrsagent, draft minutes 11:07:50 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html JonathanJ1 11:08:13 josh_soref: doug wants to specify what is requested 11:08:22 nwidell has joined #dap 11:08:25 q+ 11:09:04 ... (showing the blackberry UI) 11:09:20 ... we can already map the accept list to this type of dialog 11:09:44 fjh: can you do the camcorder case without audio? 11:10:08 josh_soref: probably not today 11:10:54 ... 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 11:11:27 shepazu: i understand where you are coming from, maybe rewrites can make it clearer 11:11:31 a12u has joined #dap 11:11:54 Takahiro has joined #dap 11:11:59 jmr_ has joined #dap 11:12:14 olivier: a lot of the discomfort came from the spec being unclear. from today, i recommend renaming it to "media file" capture 11:12:52 richt: a demo may help clear this up 11:13:12 richt: Josh_Soref has a demo that people should look at during the break. 11:13:26 fjh: we have some more time, and have covered doug's concerns (though not solved them) 11:14:00 ... you believe that we should provide the ability to ask for more granularity 11:14:19 shepazu: yes, from a privacy perspective there is additional work needed 11:14:50 ... also it would be useful to share discussion with the audio WG 11:15:14 ... some overlapping members can help us discuss this 11:15:38 fjh: we should go thru the other comments now 11:15:50 josh_soref: (showing a demo) 11:16:05 ... facebook, with a photo button 11:16:58 ... on click the button, files are offered but don't want them. another option is the selection of a new picture 11:17:54 ... the same behavior applies to other recording cases 11:18:09 fjh: going to other LC comments 11:19:17 ... 2641 was about front/back 11:19:47 anssik: this relates to the same discussion about audio/video... you should use getusermedia instead 11:20:08 ... 2637 is one we have to decide on, but not now 11:20:35 ... 2640, about html will be easy to resolve 11:21:05 ... 2638, asking for an example, we can say this is solved and do it with the other comments of doug 11:21:53 ... 2639, re camcorder as name, this seems not an issue anymore... any objectors in the room? if not, propose that we close this one 11:22:00 q 11:22:04 +q 11:22:13 ... lack of speaking up means consent 11:22:37 npdoty has joined #dap 11:22:52 nwidell: what is the relationship of the use of camcorder for getusermedia? 11:23:02 -> http://dev.w3.org/2011/webrtc/editor/getusermedia.html GetUserMedia 11:23:07 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. 11:23:07 fjh: they talk about tracks and streams, so they don't need to go there 11:23:15 s/Josh_Soref/scribe/ 11:23:56 ... 2642 is done, not sure there was a response yet. we dont need to do anything more until a response 11:24:18 Travis has joined #dap 11:24:21 ... 2644, is addressed and done, and response is OK so this is closed 11:24:26 jiro has joined #dap 11:25:01 LC-2644 +1'd by commentor at: http://www.w3.org/mid/001401cd96e5$7a73f7b0$6f5be710$@murthy@cmcltd.com 11:25:09 ... two things needed to do, informative changes (any contributors welcome) 11:25:23 (intent of my question was just if there was a need to align attribute names e.g. "camcorder" with somthing equivalent in getUserMedia 11:25:32 ... also to rename it to "HTML Media File Capture" 11:26:01 bryan: is this just to be clear that a discrete file is delivered vs a stream? 11:27:17 "HTML Media Capture" v "Media Capture and Streams" 11:27:37 fjh: 3rd things is to resolve the audio/video selection 11:27:53 s/rename it to "HTML Media File Capture/ rename it for clarity, possibly HTML Media File capture/ 11:27:54 bryan: they should be fine with the name, HTML makes it clear this is declarative 11:28:07 s/rename/consider renaming/ 11:28:15 anssik: also don't think we need to rename, they should be fine with this 11:29:01 Wonsuk has left #dap 11:29:40 fjh: so we are done with this? 11:29:42 present+ Travis_Leithead 11:30:38 fjh: would like to do more on vibration and wrap that up 11:31:31 fjh: we were talking about how it couldn't be generic as not all platforms have this feature, and testing 11:31:35 http://w3c-test.org/dap/tests/vibration/submissions/robin/TODO.txt 11:31:58 anssik: we have a todo list 11:32:37 ... i volunteered to write the tests, welcome any support. also need some hardware to test it on. 11:32:37 olivier1 has joined #dap 11:32:44 olivier2 has joined #dap 11:32:53 mounir: believe its in firefox OS 11:33:08 anssik: is there a way to emulate it somehow? 11:33:38 ... will take it offline, and talk with tizen for testing 11:34:06 jungkee: samsung colleagues implemented this for webkit 11:35:20 fjh: so we need hardware and tests for vibration to proceed? 11:35:40 anssik: writing test cases is boring without hardware to test against 11:35:59 fjh: going on to proximity and ambient light sensors 11:36:08 me can give AnssiK Tizen reference device for battery and vibra testing. 11:36:38 gmandyam: the call for exclusions for ambient light just came out 11:37:22 anssik: we have one implementation for proximity events, and it shares the design for ambient light 11:37:42 ... at least for proximity, we could move to LC. marcos did the tests for it 11:38:27 gmandyam: Ian sent an email today for exclusion 11:38:52 fjh: need to know if the WG thinks the specs are stable and can move to LC 11:39:18 * spec WD in Jul 2012: http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html 11:39:27 * test suite: http://w3c-test.org/dap/proximity/tests/submissions/marcos/ 11:39:35 fjh: who is involved with ambient light? 11:39:48 ... can do a CFC 11:39:54 s/CFC/CfC/ 11:40:12 proposed RESOLUTION: publish a LCWD of the Proximity Events spec 11:41:04 RESOLUTION: publish a LCWD of the Proximity Events spec 11:41:28 fjh: it will be after the F2F when pubrules has been checked etc 11:41:45 action: anssi to prepare Proximity LC draft and run through pubrules 11:41:45 Created ACTION-587 - Prepare Proximity LC draft and run through pubrules [on Anssi Kostiainen - due 2012-11-08]. 11:42:11 action: fjh to review exclusion period for Ambient light 11:42:11 Created ACTION-588 - Review exclusion period for Ambient light [on Frederick Hirsch - due 2012-11-08]. 11:42:52 RRSAgent, draft minutes 11:42:52 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 11:43:11 fjh: re Ambient Light Events, we should be ready for last call 11:44:12 action: fjh to send CfC for Last Call of Ambient Light Events 11:44:13 Created ACTION-589 - Send CfC for Last Call of Ambient Light Events [on Frederick Hirsch - due 2012-11-08]. 11:44:21 i/vibration and wrap/Topic: Vibration/ 11:44:46 i/proximity and ambient light sensors/Topic: proximity and ambient light sensors/ 11:44:53 topic: Network Information API 11:44:55 RRSAgent, draft minutes 11:44:55 I have made the request to generate http://www.w3.org/2012/11/01-dap-minutes.html Josh_Soref 11:45:35 fjh: Network Information API was not shelved 11:47:03 break for lunch 11:47:14 kenji has left #dap 11:47:35 smaug has joined #dap 11:48:26 giuseppe has left #dap 11:48:37 returning at 1:45 PM 11:49:38 glenn has joined #dap 12:11:50 smaug has joined #dap 12:11:58 Shinji has joined #dap 12:32:55 jiro_ has joined #dap 12:33:21 jiro_ has left #dap 12:33:46 sungok_you has joined #dap 12:34:19 Cathy has joined #dap 12:35:46 jcdufourd has joined #dap 12:41:06 whyun has joined #dap 12:41:23 hta has joined #dap 12:42:02 a12u has joined #dap 12:42:30 npdoty has joined #dap 12:46:21 kensaku has joined #dap 12:47:17 spoussa has joined #dap 12:48:04 AnssiK has joined #dap 12:50:36 adrianba has joined #dap 12:50:50 glenn has joined #dap 12:50:52 tomoyuki has joined #dap 12:51:20 Yoshihiro has joined #dap 12:51:23 tpacbot has joined #dap 12:51:41 jgiraud has joined #dap 12:52:02 bjkim has joined #dap 12:53:00 youenn has joined #dap 12:53:52 Milan_Patel has joined #dap 12:54:23 kenji has joined #dap 12:54:36 jfmoy has joined #dap 12:55:09 kinji_ has joined #dap 12:55:10 timeless has joined #dap 12:55:27 scribe: timeless 12:55:28 zakim, who is here? 12:55:28 sorry, fjh, I don't know what conference this is 12:55:29 shan has joined #dap 12:55:29 On IRC I see timeless, kinji_, jfmoy, kenji, Milan_Patel, youenn, bjkim, jgiraud, tpacbot, Yoshihiro, tomoyuki, glenn, adrianba, AnssiK, spoussa, kensaku, npdoty, a12u, hta, whyun, 12:55:31 nwidell has joined #dap 12:55:32 ... jcdufourd, Cathy, sungok_you, Shinji, smaug, Josh_Soref, richt 12:55:38 zakim, this will be DAP 12:55:39 Present+ Adrian_Bateman 12:55:39 I do not see a conference matching that name scheduled within the next hour, fjh 12:55:50 jsoh has joined #dap 12:55:51 SungOk_You__ has joined #dap 12:55:51 glenn has left #dap 12:56:02 geun_hyung has joined #dap 12:56:31 Sylvain_Lalande has joined #dap 12:56:32 topic: Network Information 12:56:36 ACTION-474? 12:56:36 ACTION-474 -- Adrian Bateman to make a proposal for Network Information API -- due 2012-10-15 -- OPEN 12:56:36 http://www.w3.org/2009/dap/track/actions/474 12:56:43 adrianba: i've had an outstanding action for a really long time 12:56:46 dom: one year 12:56:51 GregBillock has joined #dap 12:56:52 adrianba: bad news, i may not be closing it today 12:56:57 ... but i'm making progress 12:57:03 Hidetoshi has joined #dap 12:57:04 ... this is about making a proposal for a network information api 12:57:13 ... there was some disagreement 12:57:26 http://www.w3.org/TR/2011/WD-netinfo-api-20110607/ 12:57:29 eduardo_fullea has joined #dap 12:57:30 ... one about reason for using it 12:57:35 s/Josh_Soref/timeless/ 12:57:36 s/Josh_Soref/timeless/ 12:57:36 s/Josh_Soref/timeless/ 12:57:37 s/Josh_Soref/timeless/ 12:57:45 s/Josh_Soref/timeless/ 12:57:46 s/Josh_Soref/timeless/ 12:57:52 ... then there was a concern about bandwidth 12:58:02 ... and whether the right network would be selected 12:58:16 ... there were concerns about bandwidth determination and power use to determine it 12:58:22 jiro has joined #dap 12:58:23 ... W8 includes network info for applications 12:58:28 darobin has joined #dap 12:58:36 ... what i want to talk about today is giving you an update of what we're thinking 12:58:53 ... what we've heard from app developers 12:58:58 ... it may be inconclusive 12:59:04 ... the main reason for this seems to be "Bill Shock" 12:59:20 ... customer being billed for 12:59:29 ... amount of data being used 12:59:34 ... what we'd like is for applications 12:59:36 Zakim, list conferences 12:59:36 I see WAI_Indie()3:00AM, SW_LDP()2:30AM, SEC_WASWG(TPACSES)6:00AM active 12:59:38 also scheduled at this time are Team_Global(review)8:00AM, HTML_WG()4:00AM, WAI_WCAG()3:00AM, I18N_WG()6:00AM, UW_MBUI()8:00AM, UW_UWA()9:00AM, WF_TF()9:00AM, Team_(admin)08:00Z, 12:59:38 ... HTML_WG(HTML2)4:00AM 12:59:41 ... to respect the kind of network 12:59:44 ... and change their behavior 12:59:49 Jungkee has joined #dap 12:59:52 ... this can be dealt w/ at two layers in the app stack 12:59:54 Present+ Jungkee_Song 13:00:00 ... one is for the system to make appropriate changes based on the network 13:00:11 ... for the UA to make changes based on the network characteristics 13:00:17 ... network perf of your site-web app 13:00:18 robint has joined #dap 13:00:21 smaug has joined #dap 13:00:24 ... will be better because UA did intelligent things 13:00:25 JonathanJ1 has joined #DAP 13:00:31 ... app dev doesn't need to change any of their things 13:00:34 ... to get benefit 13:00:40 ... choosing to not precache video 13:00:44 giuseppe has joined #dap 13:00:45 jinhong has joined #dap 13:00:50 ... from a