15:36:48 RRSAgent has joined #dap 15:36:48 logging to http://www.w3.org/2011/11/03-dap-irc 15:36:50 RRSAgent, make logs world 15:36:50 Zakim has joined #dap 15:36:52 Zakim, this will be DAP 15:36:52 I do not see a conference matching that name scheduled within the next hour, trackbot 15:36:53 Meeting: Device APIs Working Group Teleconference 15:36:53 Date: 03 November 2011 15:38:52 spoussa has joined #dap 15:41:21 DavidKim has joined #dap 15:51:25 RRSAgent, this meeting spans midnight 15:54:28 darobin has joined #dap 15:55:02 Kihong_Kwon has joined #dap 15:56:14 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC) 15:56:35 a12u has joined #dap 15:56:51 Chairs: Frederick_Hirsch, Robin_Berjon 15:56:56 AnssiK has joined #dap 15:57:12 dsr_ has joined #dap 15:57:13 yu1 has joined #dap 15:57:13 Present+ Dominique_Hazael-Massieux 15:57:16 Present+ Anssi_Kostiainen 15:57:19 Chair: Frederick_Hirsch, Robin_Berjon 15:57:24 : Present+ Frederick_Hirsch, Robin_Berjon 15:57:26 Present+ Laszlo_Gombos 15:57:31 Present+ Frederick_Hirsch, Robin_Berjon 15:57:39 shan has joined #dap 15:57:40 Present+ Ernesto_Jimenez 15:57:42 RRSAgent, draft minutes 15:57:42 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html dom 15:58:10 +Present Travis_Leithead 15:58:22 Present+ Travis_Leithead 15:58:24 jcantera has joined #dap 15:58:25 bryan has joined #dap 15:58:34 Present+ Jose_Cantera 15:58:42 present+ Bryan_Sullivan 15:58:53 ceyrigno has joined #dap 15:59:14 marengo has joined #dap 15:59:33 dsr has joined #dap 16:00:49 scribenick: bryan 16:00:52 Present+ Marco_Marengo 16:01:11 kensaku_ has joined #dap 16:01:13 Anders has joined #dap 16:01:20 spoussa has joined #dap 16:01:26 jongyoul has joined #dap 16:01:31 Present+ Anders_Isberg 16:01:33 Present+ David_Yushin_Kim(obs) 16:01:33 Cathy has joined #dap 16:01:36 Present+ Kihong_Kwon 16:01:47 Present+ spoussa 16:01:49 Present+ Cathy_Chan 16:02:11 Present+ Christophe_Eyrignoux 16:02:37 jgiraud has joined #dap 16:02:45 Present+ Ingmar_Kliche 16:02:49 jun has joined #dap 16:03:01 Present+ Soonbo_Han 16:03:02 Present+ jerome_giraud 16:03:12 rrsagent, generate minutes 16:03:12 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 16:03:19 Soonho has joined #dap 16:03:50 Present+ Soonho_Lee 16:04:46 Present+ Jongyoul_Park 16:05:45 dowan has joined #dap 16:06:17 shunan has joined #dap 16:08:42 richt has joined #dap 16:09:13 jfmoy has joined #dap 16:09:26 fjh: introduces the DAP wiki working mode etc 16:09:33 nwidell has joined #dap 16:10:12 http://www.w3.org/2009/dap/wiki/ApiCheckList 16:10:14 ArtB has joined #dap 16:10:28 Present+ Niklas_Widell 16:10:31 Kepeng has joined #dap 16:10:35 Linuz has joined #dap 16:11:13 Frankie has joined #dap 16:13:12 Luca has joined #dap 16:15:13 Luca has left #dap 16:15:33 present+ Linuz S. Lee 16:16:29 abarsto has joined #dap 16:17:11 q+ to say something 16:17:12 q+ 16:17:23 ack dom 16:17:24 dom, you wanted to say something 16:17:32 SungOk_You has joined #dap 16:17:34 q? 16:17:41 Luca has joined #dap 16:17:46 q? 16:17:54 ack fjh 16:18:11 RRSAgent, make minutes 16:18:11 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html ArtB 16:18:16 q? 16:18:35 Anders has joined #dap 16:18:48 Present+ SungOk_You 16:18:58 present+ Sakari_Poussa 16:19:13 Present+ Anders_Isberg 16:19:50 Mauro has joined #dap 16:20:01 js has joined #dap 16:20:56 Present+ Rich_Tibbett 16:22:11 Zakim, code? 16:22:11 sorry, darobin, I don't know what conference this is 16:22:18 Zakim, this is dap 16:22:18 sorry, darobin, I do not see a conference named 'dap' in progress or scheduled at this time 16:22:43 Mani has joined #dap 16:22:51 shunan fan Huawei terminal company 16:22:53 Present+ Kepeng_Li 16:22:55 *Sakari Poussa , Intel 16:22:58 Zakim, room for 5? 16:22:59 ok, dom; conference Team_(dap)16:22Z scheduled with code 26633 (CONF3) for 60 minutes until 1722Z 16:24:27 ...agenda review 16:24:39 Team_(dap)16:22Z has now started 16:24:40 +Josh_Soref 16:24:41 topic: review of the minutes 16:24:46 Zakim, call Salon_CE 16:24:46 ok, dom; the call is being made 16:24:48 +Salon_CE 16:25:15 Slovetskiy has joined #dap 16:25:43 RESOLUTION: Minutes from 12 October 2011 are approved. 16:25:50 RESOLUTION: Minutes from 26 October 2011 are approved, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0076/minutes-2011-10-26.htm 16:25:50 +tpac 16:25:54 Zakim, drop Salon_CE 16:25:54 Salon_CE is being disconnected 16:25:55 -Salon_CE 16:25:57 topic: Battery API 16:26:03 zakim, who is here? 16:26:03 On the phone I see Josh_Soref, tpac 16:26:04 On IRC I see Slovetskiy, Mani, js, Mauro, Anders, Luca, SungOk_You, ArtB, Frankie, Linuz, Kepeng, nwidell, jfmoy, richt, shunan, dowan, Soonho, jun, jgiraud, Cathy, jongyoul, 16:26:09 ... spoussa, kensaku_, marengo, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, a12u, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, Travis_MSFT, ernesto_jimenez, fjh, lgombos, 16:26:11 ... tmpsantos, wmaslowski_, trackbot, ingmar, dom, matt, ilkka, Josh_Soref 16:27:43 dsr has joined #dap 16:28:21 Kai has joined #dap 16:28:23 anssik: battery API intro 16:29:13 jmarting has joined #dap 16:29:19 anssi: expect that folks have looked at the draft, its pretty stable and nearing last call stage 16:29:25 dsr_ has joined #dap 16:29:33 jmarting has left #dap 16:29:38 jose: main concern is no way to specify event rate 16:29:57 Present+ Josh_Soref 16:30:04 -Josh_Soref 16:30:52 http://www.w3.org/mid/4EB03375.3070702@lamouri.fr 16:31:22 anssi: Jonas (Mozilla) wants to leave that up to the implementation 16:32:11 robin: seems fine 16:32:43 jose: what does that mean to the app, does it need to filter the events? 16:33:30 anssi: the app can measure the delta 16:33:32 jgiraud has joined #dap 16:33:37 My concern is the event rate at which receive battery events 16:33:51 jcdufourd has joined #dap 16:34:17 anssi: events too often don't help as they may not be true changes 16:34:52 anssi: devs will need to handle various firing speeds 16:34:54 q+ 16:35:18 ack bryan 16:35:55 bryan: don't we have the ability to threshold? 16:35:59 anssi: no 16:36:48 Luca has left #dap 16:37:24 http://dev.w3.org/2009/dap/system-info/battery-status.html 16:39:00 bryan: dropping threshold events is an issue 16:40:14 anssi: this was based upon implementer feedback (Mozilla) 16:40:27 Moystard has joined #dap 16:41:53 dom: the orginal spec was 1% change events... if we have platforms that don't send events consistently that won't be helpful to developers 16:42:17 jfmoy has joined #dap 16:42:31 Firing events too often could be counter-productive to saving battery... 16:43:05 dom has joined #dap 16:43:11 q+ 16:43:16 http://lists.w3.org/Archives/Public/public-device-status/ 16:43:41 bryan: I will join the task force and review the comments on the list, to see how we can restore the threshold events if possible 16:45:21 lazlo: what about the use case on scaling back work when the battery is getting low? 16:45:38 anssi: its in the use cases in the spec 16:45:41 laszlo notes we need to consider both browser implementer concerns and web page author concerns 16:46:14 q- 16:47:00 jose: the monitoring of the battery will impact the battery, if it depends upon handling continual events 16:47:22 anssi: we all agree that we don't want to impact the battery by the use of the API 16:48:11 ... thresholds were not hard coded as in the future we don't know how they might apply or not 16:48:32 + +1.941.323.aaaa 16:48:35 -tpac 16:48:36 +tpac 16:48:58 zakim, who is here? 16:48:58 On the phone I see tpac, +1.941.323.aaaa 16:48:59 On IRC I see dom, jfmoy, jcdufourd, jgiraud, dsr_, Kai, dsr, Slovetskiy, Mauro, Anders, SungOk_You, ArtB, Frankie, Linuz, Kepeng, nwidell, richt, shunan, dowan, Soonho, jun, Cathy, 16:49:03 ... jongyoul, spoussa, kensaku_, marengo, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, a12u, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, Travis_MSFT, ernesto_jimenez, fjh, 16:49:06 ... lgombos, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 16:49:11 Zakim, aaaa is jlebar 16:49:11 +jlebar; got it 16:49:15 Justin Lebar 16:49:45 The time units in the specs might be difficult to get in some platforms. That is, it might be very hard to get time value. 16:49:45 Present+ Justin_Lebar 16:49:47 volkmar has joined #dap 16:50:36 anssi: the spec is designed to use defaults for charging time 16:51:16 spoussa: its hard to estimate charging/discharging time on different platforms 16:51:21 RRSAgent, draft minutes 16:51:21 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 16:51:32 spoussa: the example in the spec won't work with the defaults 16:51:44 present+ Mounir_Lamouri 16:51:50 jlebar has joined #dap 16:51:58 RRSAgent, draft minutes 16:51:58 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 16:52:38 darobin: we got feedback that complex examples are helpful 16:53:09 + +33.1.44.79.aabb 16:53:15 zakim, who is here? 16:53:15 On the phone I see tpac, jlebar, +33.1.44.79.aabb 16:53:16 On IRC I see jlebar, mounir, dom, jfmoy, jcdufourd, jgiraud, dsr_, Kai, dsr, Slovetskiy, Mauro, Anders, SungOk_You, ArtB, Frankie, Linuz, Kepeng, nwidell, richt, shunan, dowan, 16:53:17 ingmar: how is app initialization done? 16:53:20 ... Soonho, jun, Cathy, jongyoul, spoussa, kensaku_, marengo, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, a12u, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, Travis_MSFT, 16:53:22 ... ernesto_jimenez, fjh, lgombos, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 16:53:35 Zakim, aabb is mounir 16:53:35 +mounir; got it 16:53:39 Zakim, aabb is mounir 16:53:39 sorry, Josh_Soref, I do not recognize a party named 'aabb' 16:54:50 darobin: mounir has been working on the battery status in Mozilla 16:55:16 s/Linuz S. Lee/Linuz_S_Lee/ 16:55:22 anssi: one concern raised about the semantic events bring dropped 16:55:31 s/bring/being/ 16:55:41 RRSAgent, draft minutes 16:55:41 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 16:55:43 nvbalaji has joined #dap 16:55:52 ... if the web code gets too many events as a result 16:56:17 ... our concensus was that would not be an issue if implemented correctly 16:56:28 s/: Present+/Present+/ 16:56:39 mounir: we don't have the critical etc info from the battery 16:56:54 s/+Present Travis_Leithead/Present+ Travis_Leithead/ 16:57:24 ... it would be the same if the web page measured the level against some expected value 16:57:35 RRSAgent, draft minutes 16:57:35 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 16:57:46 dom: another approach is to set a delta threshold 16:58:14 s/its in the use/it's in the use 16:59:13 mounir: sending a lot of events does not seem to be bad 16:59:14 [I'll rework the example to check also against level if dischargingTime is not available] 16:59:46 mounir: about too many events, an email was sent to the list 16:59:53 present+ Jean_Claude_Dufourd 16:59:58 sriramyadavalli has joined #dap 17:00:11 http://lists.w3.org/Archives/Public/public-device-status/2011Nov/0000.html 17:01:27 darobin: if the underlying system provides too many events, the user agent would be expected to block the events 17:02:36 dom: we may be missing a valuable thing for implementations, as the high/low/critical values may be useful to the implementation as a way to optimize its battery monitoring also 17:02:41 youenn has joined #dap 17:02:44 q+ 17:03:02 robin: with 1% thresholds (implementation approach) we are talking 80 events 17:03:48 dom notes that optional threshold parameter would have value and low cost, avoid issues that developer might not recognize 17:03:53 ack anssiK 17:04:11 dom: if the developer does not know the battery level before doing resource-intensive DOM actions, it can impact the battery even more 17:04:36 q+ 17:04:52 (note that I wasn't talking about "high/low/critical" events, but having a parameter to define the threshold (set for dischargingtime, or level) from which to send the events) 17:05:12 anssi: on the list, it was stated that we don't know how the battery backends behave, so its good to leave it to the implementation 17:05:36 q+ spoussa 17:06:18 -mounir 17:06:42 So you guys have to break about now? Are we getting to vibrator before then, or is that coming later? 17:06:48 s/so its/so it's/ 17:06:58 mounir: if we have native extension listening to battery events, the platform is also optimizing the rate of events 17:07:01 jlebar, I think we'll probably take it after the break -- will ask the chairs to confirm 17:07:52 [ Conversation to confirm we're switching from Battery to Vibration to help jlebar ] 17:08:36 -jlebar 17:08:38 [ Conclusion: Vibration @10:45am Pacific ] 17:09:13 Frankie has joined #dap 17:09:14 q? 17:09:17 ack fjh 17:09:23 spoussa: additional comment to adding the level... there are backends that are already optimizable 17:09:27 ack spoussa 17:09:42 q+ 17:10:14 anssi: the platform should already optimize it without webapp help 17:10:49 sounds like this is a potentially useful optimization 17:10:51 RRSAgent, make minutes 17:10:51 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html ArtB 17:10:51 josh: the system can determine when to send events based upon whether the apps need them - when do they care 17:11:03 darobin: wakeup is important 17:11:48 josh: preventing the need to wake up just to handle the events, needs a different approach 17:11:54 JonathanJ1 has joined #DAP 17:12:28 dom: an optional threshold setting would allow the app to optimize events 17:12:40 q? 17:12:44 richt: the platform would still need to listen to the underlying events 17:12:49 ack ernesto 17:13:31 richt: if those optimizations were wide-spread, it would be fine but it depends upon that 17:15:35 dom: in many cases being able to request less events would be an optimization 17:16:38 richt notes that level is appropriate and not more is needed 17:17:11 anssi: we still have the sync interface which allows the app to get less events 17:17:15 Slovetskiy has joined #dap 17:17:20 giuseppe has joined #dap 17:17:20 q+ 17:17:27 s/less/fewer/ 17:17:28 ... the app can poll the sync interface 17:18:12 ernesto notes could have seven apps polling, want to avoid drain from executing javascript 17:18:17 darobin: even if the underlying interface needs to poll the platform continually for the sync API, it does not need to deliver the events to Javascript 17:19:19 ack richt 17:19:31 joakim has joined #dap 17:20:33 @@@: could use the constructor approach to prevent the sync API from being used when not needed 17:20:33 jcd: how about a field for the author to indicate whether he will use the sync part 17:20:46 s/@@@/jcd/ 17:21:11 richt: the current API was not designed for optimization 17:22:03 + I'm not convinced by the optimizations based on the current design 17:22:29 s/the optimizations/adding threshold optimizations/ 17:22:38 darobin: we need to have a proposal for the options and this will be the last major change so we can move on to other things 17:23:57 ACTION: Sakari to draft a proposal for a threshold parameter for Battery events 17:23:57 Created ACTION-459 - Draft a proposal for a threshold parameter for Battery events [on Sakari Poussa - due 2011-11-10]. 17:23:58 s/notes that level is appropriate and not more is needed/the design of the API to include a sync 'level' attribute prevents threshold really bringing any significant optimizations to imps/ 17:24:26 Daniel has joined #Dap 17:27:01 disconnecting the lone participant, tpac, in Team_(dap)16:22Z 17:27:02 Team_(dap)16:22Z has ended 17:27:05 Attendees were Josh_Soref, Salon_CE, tpac, +1.941.323.aaaa, jlebar, +33.1.44.79.aabb, mounir 17:28:21 a1zu has joined #dap 17:30:34 nwidell has joined #dap 17:31:18 nwidell has joined #dap 17:31:43 a12u has joined #dap 17:31:47 RRSAgent, draft minutes 17:31:47 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html shan 17:33:21 dsr has joined #dap 17:33:57 marengo has joined #dap 17:34:39 jgiraud has joined #dap 17:34:44 jfmoy has joined #dap 17:36:42 Mani has joined #dap 17:37:50 Present+ mahalingam_mani update 17:40:40 adrianba has joined #dap 17:43:13 jun has joined #dap 17:45:15 Sorry s/update// 17:47:00 Zakim, who's on the phone? 17:47:00 apparently Team_(dap)16:22Z has ended, dom 17:47:02 On IRC I see jun, adrianba, Mani, jfmoy, jgiraud, marengo, dsr, a12u, nwidell, joakim, giuseppe, JonathanJ1, youenn, nvbalaji, jlebar|lunch, mounir, dom, jcdufourd, dsr_, Kai, 17:47:06 ... Mauro, SungOk_You, Kepeng, shunan, dowan, Cathy, jongyoul, kensaku_, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, Travis_MSFT, 17:47:09 ... ernesto_jimenez, fjh, lgombos, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 17:47:11 Zakim, room for 5 for 400 minutes? 17:47:12 ok, dom; conference Team_(dap)17:47Z scheduled with code 26632 (CONF2) for 400 minutes until 0027Z 17:47:34 zakim, who is here? 17:47:34 apparently Team_(dap)16:22Z has ended, fjh 17:47:35 On IRC I see jun, adrianba, Mani, jfmoy, jgiraud, marengo, dsr, a12u, nwidell, joakim, giuseppe, JonathanJ1, youenn, nvbalaji, jlebar|lunch, mounir, dom, jcdufourd, dsr_, Kai, 17:47:39 ... Mauro, SungOk_You, Kepeng, shunan, dowan, Cathy, jongyoul, kensaku_, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, Travis_MSFT, 17:47:41 ... ernesto_jimenez, fjh, lgombos, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 17:47:54 Scribe: Josh_Soref 17:48:05 Team_(dap)17:47Z has now started 17:48:12 +tpac 17:48:19 spoussa has joined #dap 17:48:44 zakim, who is here? 17:48:44 On the phone I see tpac 17:48:45 On IRC I see spoussa, jun, adrianba, Mani, jfmoy, jgiraud, marengo, dsr, a12u, nwidell, joakim, giuseppe, JonathanJ1, youenn, nvbalaji, jlebar|lunch, mounir, dom, jcdufourd, dsr_, 17:48:48 linuz has joined #dap 17:48:49 ... Kai, Mauro, SungOk_You, Kepeng, shunan, dowan, Cathy, jongyoul, kensaku_, ceyrigno, bryan, jcantera, shan, yu1, AnssiK, Kihong_Kwon, darobin, DavidKim, Zakim, RRSAgent, 17:48:52 ... Travis_MSFT, ernesto_jimenez, fjh, lgombos, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 17:48:53 "the conference is restricted at this time" 17:49:35 q+ to request a repeat count as an optional parameter as per android's vibrator API 17:49:37 +jlebar 17:49:53 darobin: jlebar welcome back, thanks for joining us 17:49:53 richt has joined #dap 17:49:54 Soonho has joined #dap 17:50:00 Topic: Vibration API 17:50:02 Anders has joined #dap 17:50:14 darobin: opens the floor to jokes 17:50:19 Present+ Anders_Isberg 17:50:27 s/darobin: opens the floor to jokes/[ darobin opens the floor to jokes ] 17:50:52 darobin: two weeks ago, AnssiK took what Mozilla implemented and drafted a specification out of it 17:51:13 AnssiK: Mozilla has been working on an implementation known as WebVibrator 17:51:16 http://dev.w3.org/2009/dap/vibration/ 17:51:25 ... I took the liberty of naming it Vibration 17:51:38 ... i'd like to hear your opinion of what i've written 17:51:49 thanks. 17:51:58 nwidell has joined #dap 17:52:11 ... the api is simple, it lets you ask the device to vibrate for a certain period of time 17:52:30 ... it doesn't support intensity, it was proposed by huwai 17:53:17 ... the main use cases are games 17:53:29 ... and it's limited to the active web content/task 17:53:39 stakagi has joined #dap 17:53:42 s/huwai/huawei/ 17:53:45 darobin: i'd like to make sure everyone agrees that this is very simple for a version 1 17:53:50 q+ to note the API as defined looks to have the essential features, but I'm not sure about the disabling when in background 17:54:00 ... if there's interest in a more complex version, we can do a vibrator 2 17:55:15 ... we have a normative dependency to page visibility 17:55:15 darobin: i think that's actually in LC 17:55:18 AnssiK: i'd like to reuse much of it 17:55:39 jfmoy has left #dap 17:56:13 ... if page visibility is progressing on REC, then we can rely on it 17:56:19 ... i think mozilla is dependening on mozHidden 17:56:36 s/dependening/depending/ 17:56:58 AnssiK: we public the FPWD after we get confirmation from jlebar to confirm it's ok 17:57:13 q+ darobin 17:57:13 ... and then we can bike shed about naming 17:57:13 q? 17:57:13 q+ darobin 17:57:14 q+ robin 17:57:16 q+ 17:57:26 q- robin 17:57:28 ack dsr_ 17:57:28 dsr_, you wanted to request a repeat count as an optional parameter as per android's vibrator API 17:57:40 dsr_: i've been doing an impl for android 17:57:51 ... and there's a need for a repeat count for a pattern 17:57:56 AnssiK: what's the UC? 17:58:11 dsr_: it's to avoid repeating yourself 17:58:11 q+ 17:58:24 dsr_: wouldn't it be easier to do it in the api? 17:58:37 darobin: i think on iOS you can only just vibrate 17:58:47 ernesto_jimenez: at least the phonegap iOS it only vibrates 17:58:55 AnssiK: i'm not opposed, i just need UCs 17:59:00 I agree: I'm in favor of a compact API surface. 17:59:04 q+ to talk about different haptics and constraints 17:59:16 jfmoy has joined #dap 17:59:16 ack dsr_ 17:59:24 jcantera: what you're suggesting wouldn't work 17:59:35 ... dsr is suggesting vibration slots 17:59:41 I'll mention my point now while it's relevant: I'd prefer a vibrateend event, so I can perform a js loop of the vibrate behaviour as many times as I like (rather than specifying an optional repeat parameter) 17:59:46 ... and repeating the slots as many times as you want 18:00:01 ... basically the Array 18:00:11 AnssiK: my point is that it's a convenience 18:00:18 I don't see the repeat count as more than an optimization, a convenience 18:00:30 ... JS has a way to do stuff natively to Arrays 18:00:39 q? 18:00:43 ... I could also then trigger some action on vibration end. 18:00:49 darobin: jcantera is talking about vibration patterns 18:00:56 It's easy to create a pattern that has a certain length and repeat it at will until an event causes the app to cancel it 18:01:13 ... if you want to repeat it, you'd need to when it's going to end 18:01:13 ... if you want to start it again 18:01:21 ack bryan 18:01:21 bryan, you wanted to note the API as defined looks to have the essential features, but I'm not sure about the disabling when in background 18:01:30 bryan: to me, a repeat option is an optimization 18:01:36 ... it's a convenience 18:01:43 ... my pattern itself can repeat 18:01:47 AnssiK: i don't see it as a big issue 18:01:50 q- 18:01:57 q? 18:02:20 bryan: the API as defined looks to have the essential features, but I'm not sure about the disabling when in background 18:02:31 ... i think there are use cases when my page is in the background 18:02:37 ... and it wants to notify 18:02:43 AnssiK: Out Of Scope 18:02:52 ... that should be covered by the notification API 18:02:53 Adroid's vibrate API has a method that takes a pattern just as in the current draft spec, and a further parameter that is a repeat count. This is a convenience for developers. 18:02:57 ... it could be by Heating Up 18:03:01 ... at least our devices do that 18:03:13 [ Laughter ] 18:03:13 darobin: WebNotification 18:03:30 sicking has joined #dap 18:03:32 ... If you have a tab/page in the background 18:03:39 q+ 18:03:46 ... you use WebNotification, and it will use the user's preferred way of being notified 18:03:47 s/our devices/some devices/ 18:03:52 ... it might heat up in your pocket, 18:04:02 ... or it might vibrate, or make sound, or show something on screen 18:04:11 q+ to talk about stop 18:04:22 bryan: so notification api gives me a way to vibrate in the background? 18:04:41 Josh_Soref: the notification api lets you trigger a notice, if the user chooses that it be a vibration, then you're triggering a vibration 18:04:45 [ Time Check ] 18:04:46 Present+ Adrian_Bateman 18:05:02 bryan: i don't think my UC benefits from WebNotification 18:05:18 ... my web app wants to control how it interacts with the user 18:05:20 ack darobin 18:05:43 darobin: if you have a UC not covered by WebNotification or Vibration, then please send feedback to the list 18:05:50 darobin: I wanted to ask jlebar (on the call) 18:05:59 ... in terms of functionality, are you happy with what you have in the api? 18:06:11 ... or are you looking to add things? 18:06:18 jlebar: this isn't a notification api 18:06:23 ... the ability to turn vibration on 18:06:35 ... and turn it on with a given pattern is all we need 18:06:40 AnssiK: what about intensity? 18:06:47 jlebar: I do think it's interesting 18:06:51 ... but i don't know how we do that 18:06:56 ... i don't know enough about devices 18:06:56 efidler has joined #dap 18:07:00 ... to speak to that 18:07:11 ... we'd have to survey devices 18:07:13 AnssiK: makes sense to me 18:07:15 q? 18:07:17 ack jcantera 18:07:21 abarsto has joined #dap 18:07:31 jcantera: in Android, you don't have a way to control intensity by default 18:07:42 ... but with a given device, you may be able to use Immersion to control it 18:07:53 ... maybe we can provide optional parameters to do it 18:08:00 ... intensity, style, whatever 18:08:04 jmarting has joined #dap 18:08:12 ... provide some extensibility for it 18:08:21 AnssiK: i suggest jcantera send a proposal to the list 18:08:33 ... it would be helpful for someone to survey the native apis 18:08:53 jcantera: i think the api can be opened to such a feature 18:08:58 dom: this could be a v2 feature 18:09:14 AnssiK: we need to be very careful about scope 18:09:18 ... we have lots of haptic feedback mechanisms out there 18:09:25 jcantera: having an optional parameter in the method 18:09:34 dom: then you need to define how that works 18:09:48 darobin: you need to define how things are interpreted, ignored, etc 18:09:50 ack fjh 18:10:18 fjh: dsr_ was asking about a repeat parameter 18:10:24 ... usability for authors is important 18:10:32 ... even if it's just syntactic sugar 18:10:40 ... i think we can do a FPWD w/o things being perfect 18:10:45 ... we can publish regardless 18:10:54 ack fjh 18:11:14 darobin: we can say that the implementation just multiplies the array 18:11:14 ack Josh_Soref 18:11:14 Josh_Soref, you wanted to talk about different haptics and constraints 18:12:14 anne has joined #dap 18:12:24 Josh_Soref: in nokia we had to look at hap haptics and we had to worry about buffers 18:12:37 anne has left #dap 18:12:39 sicking: pass 18:12:39 Josh_Soref: bandwidth of buffer might be another reason for repeat count 18:12:44 ack sicking 18:13:00 sicking: while repeat pattern makes things easier 18:13:12 ... it does mean an extra parameter that we have to care about 18:13:19 ... it makes it a bit harder for extending later 18:13:27 ... i would like to see a solution for intensity 18:13:34 ... is intensity support in devices common? 18:13:41 ... for advanced gaming systems you have a lot of that 18:13:51 darobin: for AGS, you have multiple devices 18:13:56 ... clearly a v2 feature 18:14:00 ack adrianba 18:14:00 adrianba, you wanted to talk about stop 18:14:14 adrianba: given that you can dispatch this pattern 18:14:14 ... what if you want to stop it? 18:14:26 darobin: i think if you call vibrate, it interrupts the previous pattern 18:14:30 q+ 18:14:40 (or vibrate(-1) ?) 18:14:41 ... calling vibrate(null) will stop 18:14:54 q? 18:14:58 ... we could add a close method 18:15:00 ack Kepeng 18:15:12 ... but we're moving to navigator 18:15:14 ack Kepeng 18:15:35 ... so we need to be careful about not canceling navigator 18:15:55 Kepeng: understanding of the vibrating api 18:16:01 ... is to invoke the device to vibrate 18:16:13 ... do we have a way to ask if the device is vibrating? 18:16:13 AnssiK: we don't support that 18:16:21 .... i proposed events for starts/stops 18:16:27 s/..../.../ 18:16:33 ... but we didn't have a UC for it 18:16:38 we need use cases if we need this 18:16:38 q+ 18:16:41 darobin: if you have a UC for it, please send it to the list 18:16:47 Kepeng: ok 18:16:50 q? 18:16:56 Zakim, close the queue 18:16:56 ok, Josh_Soref, the speaker queue is closed 18:17:01 ack richt 18:17:13 richt: i like Kepeng 's idea 18:17:13 ... i'd like to know when my vibration ends 18:17:20 ... so i can know i can do my next action 18:17:26 ... but there's a need for a timeout 18:17:33 ... and i get some latency/jag 18:17:39 darobin: agree, send UC to list 18:17:50 q? 18:18:14 ack jcantera 18:18:16 q- jcantera 18:18:29 darobin: objections to a FPWD? 18:18:31 action: fjh to send cfc for FPWD for vibration 18:18:31 Created ACTION-460 - Send cfc for FPWD for vibration [on Frederick Hirsch - due 2011-11-10]. 18:18:32 Zakim, open the queue 18:18:32 ok, dom, the speaker queue is open 18:18:33 [ none ] 18:18:42 darobin: implementers, please send us feedback 18:18:46 ... now would be nice 18:19:15 ... jlebar, if you've had the time, it would be good to get feedback 18:19:15 jlebar: offhand it looks mostly good 18:19:22 darobin: any other implementers looking at it? 18:19:34 richt: i'd like to see a path from a v1 to a v2 in the spec 18:19:35 sriramyadavalli has joined #dap 18:19:42 on thinking about the possible use cases for background vibration, I think there are perhaps some corner use cases but no central ones, and the possible unwanted side-effects (e.g. conflicts between multiple background pages) would need to be considered - so for now I don't plan to submit any use cases for that 18:19:45 ... like supporting multiple targets 18:19:56 darobin: thanks jlebar for joining us 18:19:57 thanks, bryan 18:20:11 Topic: Media Capture 18:20:13 Bye, everyone. I"ll send mail to the list soon. 18:20:22 -jlebar 18:20:34 Travis_MSFT: I have remarks 18:20:42 Zakim, who's on the call? 18:20:42 On the phone I see tpac 18:20:49 darobin: Media Capture, there are two drafts 18:21:16 ... the one thing we're missing for media capture 18:21:23 ... is for someone to tell us which attributes they want 18:21:29 ... right now, it's bikeshedding 18:21:39 ... first implementer to suggest hints, it'll probably be adopted 18:21:52 ... [this is style] 18:22:01 ... the second case is programatic input 18:22:13 ... the proposal is to have a joint list between WebRTC and DAP 18:22:16 JariA has joined #dap 18:22:24 ... concerns of a joint work with WebRTC? 18:22:39 dom: until recently, DAP had adopted the Media Capture API 18:22:44 ... getUserMedia() 18:22:59 ... and there was something similar in WebRTC 18:23:13 ... the proposal was to make this a joint proposal, to replace the existing work 18:23:33 jcantera: does getUserMedia() give a preview? 18:23:38 ... but you need a way to capture 18:23:40 [the existing DAP Media Capture API http://dev.w3.org/2009/dap/camera/Overview-API.html ] 18:24:12 darobin: no specific concerns to the task force, i'll set it up 18:24:32 Travis_MSFT: Travis, I joined this group recently 18:24:39 ... I've been in WebApps since 2006 18:24:57 ... I've been working on Web pages/ the IE team, Trident, 7, 8, 9, 10 18:25:12 ... my primary interest in the short term is Media Capture 18:25:16 ... I recognize there's a lot of prior history here 18:25:21 ... putting that behind me 18:25:27 abarsto has joined #dap 18:25:28 ... i'm a proponent for the TF 18:25:42 ... it's a way to get our point of view form the Local MC perspective 18:25:56 ... and trying to merge that with the remote point of view from WebRTC 18:26:11 ... in Feb of this year, the Speech team at MS sent feedback 18:26:27 http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0015.html 18:26:28 ... they expressed concern of enumerating device characteristics of the Camera 18:26:43 ... those things are conspicuously absent from the WebRTC proposal 18:26:57 ... with getUserMedia(), we now have a way to put user consent 18:27:02 ... which was lacking before 18:27:12 privacy concerns due to the use of this info for fingerprinting or otherwise? 18:27:12 q+ to mention consent item 18:27:14 ... we can hide things behind that layer 18:27:40 ... direct access to the Stream rather than brokering 18:27:49 darobin: quite a lot of agreement on that 18:27:53 At the same time, the recent Streams proposal [http://html5labs.interoperabilitybridges.com/streamsapi/] is another potential vehicle for previewing a capture device--it's lightweight and works for the basic scenario of hooking a capture device up to a VIDEO tag. We should think about the benefit that a Stream might provide both in terms of recordings as well as preview. Of course, the use 18:27:54 of MediaStream will certainly be necessary if the local capture scenario transitions into an RTC scenario. 18:28:29 http://html5labs.interoperabilitybridges.com/streamsapi/ 18:28:29 Travis_MSFT: consuming Streams instead of Fixed Blobs could be useful 18:28:36 ... either for getting or previewing 18:28:46 [ a couple of people have looked at the Streams proposal ] 18:28:55 adrianba: the WebApps group agreed to adopt it as a deliverable 18:29:03 AnssiK: is WebRTC discussing using it? 18:29:15 [ Maybe ] 18:29:15 Travis_MSFT: the other thing from the speech people 18:29:20 ... was the concept of endpointing 18:29:24 ... when i open myphone 18:29:31 ... and perform a search 18:29:39 ... when i click here 18:29:47 ... it's listening to me, and it knows when i stop talking 18:30:00 ... it can make value judgments about when to capture data 18:30:11 .... very useful for speech recognition 18:30:11 s/..../.../ 18:30:23 Travis_MSFT: i don't have a solution, but we have an interest 18:30:32 q? 18:30:37 ... if we consider MediaStream as the starting point 18:30:51 ... there are scenario conflicts that are interesting that i'd like to bring up 18:31:11 -> http://dev.w3.org/2011/webrtc/editor/webrtc.html WebRTC Editors draft 18:31:14 ... a MediaStream represents a continuous source of Video and/or Audio 18:31:14 ... there's a series of tracks 18:31:17 ... (that's in flux) 18:31:23 -> http://dev.w3.org/2011/webrtc/editor/webrtc.html#mediastream WebRTC Media Stream 18:31:24 ... and it's possible to turn them on or off 18:31:46 ... I couldn't come up with a UC for turning off Audio when i'm just recording Audio 18:31:53 ... i'd just stop recording Audio in that case 18:31:57 ... it just seems strange 18:31:58 How does the stream API proposal relate to what is referenced from the File API as the "Stream API" (http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html) 18:32:11 ... as jcantera mentioned, 18:32:19 ... devices tend to have an optional mode they switch to to take a picture 18:32:26 sejinpark has joined #dap 18:32:32 ... the WebRTC proposal is missing a way to switch into that mode 18:32:40 darobin: and it prevents a way to get good pictures 18:32:42 q+ 18:32:55 ... because the time cost results in downgrading your camera by 5 years 18:33:01 dom: and it has privacy concerns 18:33:18 Travis_MSFT: our local proposal needs to have a way to "take a picutre" 18:33:22 s/picutre/picture/ 18:33:32 ... there's a concept of whether a stream is Mutable/immutable 18:33:46 ... as to whether tracks can be dynamically added/removed from a Stream 18:33:55 ... which this group should provide feedback 18:34:11 ... when yous tart recording from the camera, you merge audio+video 18:34:16 s/picture"/picture", switching to higher resolution mode for video camera/ 18:34:19 ... and having to split that up requires a lot more mwork 18:34:28 s/yous tart/you start/ 18:34:31 s/mwork/work/ 18:34:36 ... three more things 18:34:42 Travis_MSFT: the spec says you Record 18:34:56 ... taking things from the Stream and start to save it to memory/disk 18:35:15 ... the api today provides the ability to create overlapped recordings 18:35:21 ... i don't know if that's intentional, or just fallout 18:35:28 ... i'm not sure it makes a lot of sense 18:35:37 ... for end users to create multiple recordings, and start and stop them 18:35:46 ... the api might benefit from refactoring 18:35:55 darobin: i don't know of a professional camera that allows that 18:36:13 Travis_MSFT: I attended WebRTC as an observer on Tuesday 18:36:17 ... everyone was in agreement that not having a way to stop a recording was crucial 18:36:28 ... you start a recording, and get a blob back 18:36:39 ... and it just keeps going, for hours 18:37:00 ... there's a lot of small capabilities we might add: volume control 18:37:13 ... image stabilization, video effects, brightness, saturation 18:37:20 ... things you might see in camera settings 18:37:36 ... i have a desigfn philosophy, build something for the common scenarios, and make them easy 18:37:44 ... but for other things, push them out to v2 18:37:48 ... but keep them in mind 18:37:49 q? 18:37:52 s/desigfn/design/ 18:38:13 Travis_MSFT: i'm suggesting to consider more, an then make a smart selection of a subset 18:38:15 ... and push the others out of scope into v2 18:38:21 darobin: we might support 0 in the first version 18:38:26 Travis_MSFT: also viable 18:38:37 darobin: it seems orthogonal to capturing stuff 18:38:40 ack fjh 18:38:40 fjh, you wanted to mention consent item 18:38:47 fjh: one q, one c 18:38:50 ... on privacy 18:39:12 q+ 18:39:14 ... i looked at the EU opinion on privacy 18:39:23 ... and have an email concerning consent on the mailing list 18:39:33 ... consent needs to be informed 18:39:42 ... i'm not sure information about what's going to happen 18:39:49 ... is presented 18:39:57 ... the other, is privacy implications to metadata 18:40:11 ... i'm not sure you have an opinion on it 18:40:18 ... i think you're saying none of it provides any 18:40:24 darobin: in terms of things 18:40:30 ... the api won't expose metadata 18:40:36 ... but the device might embed exif 18:40:43 ... whicih might disclose your geolocation 18:40:45 ack richt 18:40:49 note on privacy and consent, http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf 18:40:51 s/whicih/which/ 18:40:58 richt: our objectives... 18:41:15 ... specifically local media capture 18:41:18 ... you've talked about local UCs 18:41:25 ... not excessively redoing 18:41:32 ... WebRTC has stuff 18:41:40 ... there is the ability to copy to canvas 18:41:47 ... you can detect silence w/ audio apis 18:42:00 ... I want to recapture those UCs because they got lost in WebRTC 18:42:11 privacy and consent, correct link -> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0091/dap-privacy-wp187.pdf 18:42:13 ACTION Travis to submit UCs 18:42:13 Created ACTION-461 - Submit UCs [on Travis Leithead - due 2011-11-10]. 18:42:22 action-461? 18:42:22 ACTION-461 -- Travis Leithead to submit UCs -- due 2011-11-10 -- OPEN 18:42:22 http://www.w3.org/2009/dap/track/actions/461 18:42:30 s/note on privacy and consent,/ignore this line/ 18:42:36 ACTION rich to submit UCs 18:42:36 Sorry, couldn't find user - rich 18:42:46 ACTION richt to submit UCs 18:42:49 Created ACTION-462 - Submit UCs [on Richard Tibbett - due 2011-11-10]. 18:42:52 q? 18:42:55 ack bryan 18:42:58 ack bryan 18:43:11 RRSAgent, make minutes 18:43:11 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html ArtB 18:43:15 bryan: the stream api was discussed in webapps in the context of fileapi 18:43:19 ... there's a reference coming from whatwg 18:43:25 ... the goal is to ensure 18:43:36 ... we apply them consistently in as many places as possible 18:43:42 ... writing, reading, pushing, etc. 18:43:46 ... is that a goal? 18:43:59 trackbot: i share richt 's view that we should reuse things from the platform 18:43:59 Sorry, Josh_Soref, I don't understand 'trackbot: i share richt 's view that we should reuse things from the platform'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 18:44:21 s/trackbot/Travis_MSFT/ 18:44:49 q? 18:45:12 darobin: i think we can make progress! 18:45:17 ... you didn't talk about html Media Capture 18:45:28 thanks to travis for comments and work on this 18:45:31 Travis_MSFT: it's come up internally 18:45:37 ... in terms of UCs 18:45:42 ... personally 18:46:16 ... there is sufficient room on the web for declarative (not requiring scripts) and imperative (programmatic) 18:46:16 ... and i don't think they have to be mutually exclusive 18:46:22 darobin: one thing that would be useful is 18:46:26 q+ to talk about next steps wrt WebRTC TF 18:46:34 ... finalizing that hint 18:46:52 darobin: again, first suggestion will probably ship 18:46:58 sicking: our current approach 18:47:15 ... first step is deciding on a UI 18:47:15 ... for declarative 18:47:23 ... once we get our UX people 18:47:33 ... we'll figure out attributes in order to support those UCs 18:47:44 ... a constraint, if we need a dramatically different page ui 18:47:59 ... then we'll need a way to do things which lets pages opt in 18:48:13 ... because that would otherwise break page layout 18:48:17 darobin: any early drafts? 18:48:21 sicking: not really 18:48:33 q+ to ask about next steps with draft? 18:48:34 Travis_MSFT: i thought through this a bit 18:48:43 ... when you want to capture only audio 18:48:50 ... it seems entirely different from video 18:49:00 ... and it seems fairly hard w/o a hint 18:49:16 richt: android stock browser has a declarative approach 18:49:26 ... and things get passed off to the native control 18:49:34 ... which controls resolution, quality, etc 18:49:39 ... a user cchoice 18:49:45 darobin: which is good, right? 18:49:48 [ Yes ] 18:49:58 richt: i agree, we do a design, and see if there are any hints 18:50:21 ... sicking is right, we get the UI right, and then decide on params 18:50:35 darobin: we won't be working on HTML MC before we get UI feedback 18:50:42 ack dom 18:50:42 dom, you wanted to talk about next steps wrt WebRTC TF 18:50:46 ack dom 18:50:56 dom: we talked about getUserMedia() 18:51:13 ... we're interested in a Joint TF 18:51:16 ... that has logistic consenquences 18:51:24 ... a new TF to join, a new mailinglist 18:51:31 ... WebRTC hasn't agree to it yet 18:51:50 ... darobin and i were at WebRTC where it was discussed, but not approved 18:52:15 ACTION darobin to draft a joint TF proposal with WebRTC 18:52:15 Sorry, couldn't find user - darobin 18:52:28 dom: one thing we'll need to do is provide resources, such as an editor 18:52:39 adrianba: we found Travis_MSFT 18:52:46 fjh: what's next? 18:52:58 s/consenquences/consequences/ 18:53:10 q? 18:53:12 ACTION berjon to draft a joint TF proposal with WebRTC 18:53:13 Created ACTION-463 - Draft a joint TF proposal with WebRTC [on Robin Berjon - due 2011-11-10]. 18:53:13 q- 18:53:44 dom: We'll need the right API to get-web-user-media nicely for WebRTC to build on 18:53:58 darobin: since they're coming from the network point of view 18:54:11 ... they don't care much 18:54:30 ... but we'll need to provide something, otherwise our UC might be painful 18:54:37 Travis_MSFT: I have thoughts 18:54:40 nwidell has joined #dap 18:54:44 richt: they're also on a fast schedule 18:54:56 darobin: i think everyone's happy about that 18:55:40 dom: Travis_MSFT, you'll be on calls? 18:56:03 fjh: our calls are 10a Eastern 18:56:12 dom: but TF might be different 18:56:22 fjh: back at 1pm 18:56:28 ... talking about sensors 18:56:46 ... we'll skip network info 18:57:59 darobin: we'll move network info to tomorrow morning? 18:58:14 ... in the second session 18:58:14 [ Lunch ] 18:59:16 nwidell has joined #dap 19:00:12 RRSAgent, make minutes 19:00:12 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html shan 19:00:46 jfmoy has joined #dap 19:01:23 a1zu has joined #dap 19:07:12 JariA has joined #dap 19:08:05 sriramyadavalli has joined #dap 19:10:32 JariA has left #dap 19:30:20 sejinpark has joined #dap 19:32:34 dsr_ has joined #dap 19:33:44 jfmoy has joined #dap 19:42:50 Kihong_Kwon has joined #dap 19:44:18 sicking has joined #dap 19:47:25 marengo has joined #dap 19:53:01 Cathy has joined #dap 19:54:59 ernesto_jimenez has joined #dap 20:03:51 jgiraud has joined #dap 20:04:01 jfmoy has joined #dap 20:05:27 kensaku has joined #dap 20:05:52 yu1 has joined #dap 20:06:33 shan has joined #dap 20:06:39 a12u has joined #dap 20:07:02 lgombos has joined #dap 20:09:16 shunan has joined #dap 20:09:20 Youngsun has joined #dap 20:09:20 Travis_MSFT has joined #dap 20:09:30 scribe: Travis_MSFT 20:09:52 spoussa has joined #dap 20:09:53 kensaku has joined #dap 20:09:56 nwidell has joined #dap 20:10:17 [Round of introductions] 20:10:21 fjh has joined #dap 20:10:56 richt has joined #dap 20:11:34 SungOk_You has joined #dap 20:11:48 Topic: Sensors 20:11:52 bryan has joined #dap 20:12:01 topic: Sensor API 20:12:23 -> http://dev.w3.org/2009/dap/system-info/Sensors.html Sensors API editors draft 20:12:26 s/Topic: Sensors// 20:12:34 HF: I will be presenting the Sensors API. 20:12:51 ... current draft is 2 months old. 20:13:11 ... we've been creatingn a prototype to demostrate the feasability of the current specification 20:13:23 The link (http://dev.w3.org/2009/dap/sensors.html) for "Latest editor's draft:" is incorrect 20:13:27 ... I will be presenting the results of the prototype. Later I will present the conclusions that represent the current issues. 20:13:27 ceyrigno has joined #dap 20:13:47 AnssiK has joined #dap 20:13:50 darobin: you have demos? 20:13:57 ... yes. Will show them 20:13:58 Anders has joined #dap 20:13:59 Present+ Christophe_Eyrignoux 20:14:12 Present+ Anders_Isberg 20:14:13 ... First, establish a connection to a sensor. 20:14:34 ... Then you start watching the sensor (having provided the options, such as interval) 20:14:41 ... Then you get info via an event handler. 20:14:47 s/... yes./HF: yes./ 20:15:13 ... There's also a way to determine what sensors are available. 20:15:25 ... list the sensors. 20:15:28 JariA has joined #dap 20:16:00 ... The prototype is on Android. Using SDK and NDK to get access to the sensors 20:16:00 jgiraud has joined #dap 20:16:03 Present+ Ilkka_Oksanen 20:16:17 ... NDK to be able to interact with the sensors in C++. 20:16:21 Present+ Jari_Alvinen 20:16:29 http://developer.android.com/sdk/ndk/index.html 20:16:32 ... The also use a web browser component. 20:16:42 s/The/They/ 20:16:55 Mauro has joined #dap 20:17:18 q+ 20:17:30 ... From the web view, a JavaScript->Java conversion takes place, then a Java->C++ to get to the sensors themselves. 20:17:48 ... Sensor metadata is partially implement. 20:17:55 nvbalaji has joined #dap 20:18:00 q? 20:18:11 DKA has joined #dap 20:18:13 q- 20:18:27 ... [presenting the demo] 20:18:40 dsr has joined #dap 20:19:24 jose notes logical sensors provide a view on other real sensors, e.g. linearAcceleration ignores gravity 20:19:26 Present+Balaji_NV 20:19:50 s/Present+Balaji_NV/Present+ Balaji_NV/ 20:19:56 Linuz has joined #dap 20:19:56 [Sensor.name and Sensor.vendor create fingerprint issues] 20:20:51 ... units appear to be different even among different Android devices. 20:21:13 ... not sure if they are using different units. 20:22:12 [all] applause! 20:22:21 ... any requests or anything else you'd like to see? 20:22:25 npdoty has joined #dap 20:22:54 Travis_MSFT has joined #dap 20:23:38 q? 20:24:43 q+ 20:25:11 ack richt 20:25:11 ack richt 20:25:31 Ruinan has joined #dap 20:25:48 richt: This appears to look like the system infomation API? 20:26:11 dom: There is some overlap, though it's not exactly the same. I share some of your concerns. 20:26:33 Marcos has joined #dap 20:26:40 +q Marcos 20:26:52 ... one of the concerns with system API is using a vocabulary-based approach and an API that relies on that vocabulary. 20:27:21 richt: system API had too many features... 20:27:33 ... but it's design paradigms are valid. 20:27:34 ryoichi has joined #dap 20:27:42 RRSAgent, draft minutes 20:27:42 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 20:27:56 ... With the sensors API, some of the richness is now lost in this version 20:27:58 ack marcos 20:28:29 Marcos: I have a similar question: If I have multiple sensors (like in my car and out), how do I determine that. 20:28:39 ... How much feedback are you looking for? 20:28:49 q? 20:28:50 darobin: all feedback. 20:29:12 Marcos: can you just say "new Sensor" and then get the options? 20:29:30 Travis_MSFT has joined #dap 20:29:36 Present+ Jean-Francois_Moy 20:29:37 fluffy has joined #dap 20:29:50 Marcos: I'm a little worried that this is tied too much to mobile devices... 20:30:12 ... Can we make this more of a general use API. Specifically looking at Magnetic fields interface.... 20:30:15 this definitely relates to the "web of things" concept. 20:30:22 ... Seems to duplicate what other WG's are doing (orientation) 20:30:30 i.e. a sensor is a thing (a service). 20:30:36 HR: One of the open issues is to rename the interfaces to avoid confusion. 20:30:59 Marcos: Can you capture all 100,000 sensor types? What is the scope of this specificiation? 20:31:15 s/specificiation/specification 20:31:21 HR: We've been discussing this. Like discovery of sensors that are not on the local device 20:31:31 Marcos: Like sensors composed of other sensors? 20:31:34 abarsto has joined #dap 20:31:44 s/HF:/Jose:/g 20:31:47 dom: Every year a new device comes to market with a new sensor 20:31:56 s/HR:/Jose:/g 20:32:11 HR: If there is some kind of logical sensor--an aggregate of the physical sensors, you could deal with it that way. 20:32:23 q+ to ask what will you do with the data on average? 20:32:40 q+ 20:32:58 HR: the API is flexiable enough to be extensible. 20:33:13 ack me 20:33:13 Josh_Soref, you wanted to ask what will you do with the data on average? 20:33:18 ack Josh_Soref 20:33:32 jfh: Point is it's not a generic API that can handle future sensors. 20:33:45 s/jfh/fjh/ 20:33:45 Josh_Soref: What do you expect to be able to do with the sensors? 20:34:13 ... Discovery of the sensors independently may not have sufficient value and could lead to privacy concerns 20:34:16 giuseppe has joined #dap 20:34:24 s/Point is it's not a generic/I believe Marcos is saying it should be a generic/ 20:34:39 q? 20:34:45 ... Also, no two devices have the same level of accuracy. On the web it's nice to have an API that's slightly less capable, but can be used on the Web. 20:35:12 ... When the high-precision device is available in a limited set of devices, then it's not as useful on the web. 20:35:59 Present+ Rich_Tibbett 20:36:03 ... Example, Geoloc. has a precision. Noted, that precision might not be to the inch. Geoloc spec has a generic location. 20:36:12 q+ 20:36:15 +q Marcos 20:36:22 Present+ npdoty 20:36:23 q+ 20:36:29 [sensors.list() would at the very least minimization, by which you could get a list of sensors per type] 20:36:40 slightlyoff has joined #dap 20:36:45 ... A game might be able to say it supports only specific devices w/sensors, but that's exclusionary rather than inclusive on the Web. 20:36:59 q+ 20:37:15 q? 20:37:19 ack nvbalji 20:37:25 q+ 20:37:27 ack nvbalaji 20:37:37 s/ack nvbalji// 20:37:44 Balaji: having a generic sensors API--we should be careful. 20:37:52 ... privacy requirements are different. 20:38:12 ... if trying to do a generic service, we should be careful about privacy. 20:38:12 Luca has joined #dap 20:38:22 ... where everything can be discovered and used in the same way. 20:38:32 q? 20:38:33 Marcos: that's orthogonal to the privacy problem. 20:38:40 ack fjh 20:38:44 fjh: getting a little confused. 20:39:18 ... Is this an attempt to be a generic sensor intrface that can handle many things; I also think Marcus was suggesting this. 20:39:33 s/intrface/interface/ 20:39:36 Privacy sensor may have different privacy requirement compared to Location sensor 20:39:42 ... but if this is so generic we might not be able to handle the plethora of devices. 20:39:49 ... didn't really understand Josh's comments 20:40:13 ... I understand that precision matters. 20:40:13 Josh_Soref: the raw orientation scares me. 20:40:36 ... I don't see any use cases for that other than having-or-not that sensor. 20:40:46 q? 20:40:49 ack Marcos 20:40:56 Marcos: vendor attribute -- I have concerns about that as well., 20:41:02 +! 20:41:11 a big +1 on not duplicating deviceorientation 20:41:14 s/+!// 20:41:14 +1 20:41:14 and another +1 on exposing vendor 20:41:15 q+ 20:41:28 ... A vendor identification should not be exposed because it risks that an app can be built around just that vendor. 20:41:31 vendor issue for fingerprinting 20:41:40 HR: It does't invalidate the API 20:41:55 s/does't/doesn't/ 20:42:01 s/HR:/Jose:/ 20:42:03 Marcos: Just because the data is there, doesn't mean it must be exposed. 20:42:12 Josh_Soref: isn't this already resolved? 20:42:19 fjh: Yes, resolved. 20:42:22 q- 20:42:58 jun has joined #dap 20:43:11 linuz has joined #dap 20:43:14 ack bryan 20:43:15 Marcos: Android has this exposed. I wonder why they added it? What was there use case? 20:43:18 lgombos: do we have vendor interest in implementing this? 20:43:26 [or maybe they added it because they could; that's what it sounds like we would be doing as well] 20:43:32 zakim, what did you just say? 20:43:32 I don't understand your question, fjh. 20:43:36 Soonho has joined #dap 20:43:40 q? 20:43:52 bryan: Be careful to avoid not standardizing a device just because it might be disenfranchied. 20:44:23 ... For use cases, in a lot of cases, you want to personalize your experience (see augmented reality, games, etc.) 20:44:24 jlebar has joined #dap 20:44:25 Kai has joined #dap 20:44:40 ... yes, don't dup functionality exposed elsewhere. 20:44:59 q? 20:45:11 ... Web platform will suffer if this data is exposed elsewhere (but not on the web). 20:45:15 jcantera has joined #dap 20:45:18 q- 20:45:52 ack slightlyoff 20:45:52 ack slightlyoff 20:46:13 Alex Russel (google): Two contentions points: 20:46:26 slightlyoff is alex russel 20:46:30 ... gradients of potential specificity is related to the data type itself. 20:46:46 s/alex russel/alex russell/ 20:47:00 s/Russel/Russell/ 20:47:01 ... In input type=file we don't ask for the type, we let the user determine. 20:47:16 ... Rather than a specific API, this seems more like markup 20:47:31 RRSAgent, draft minutes 20:47:31 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 20:47:46 ... Should this be an API? With Web Intents, there may be a way for service description/discovery that is parallel to other ssystems in the platform. 20:47:54 s/ssystems/systems/ 20:47:58 q? 20:48:15 darobin: Interacting with the data-type is useful. Not sure about translating into markup. 20:48:28 AR: Markup provides a way to describe defualt user-interaction in UA's that don't support it. 20:48:33 agree that this could be reduced to the problem of providing data in Web Intents / Discovery 20:48:42 q? 20:48:44 q+ robin 20:48:45 ... since markup is not specific by default, it's a good starting point. 20:48:52 Marcos: agree generally. 20:49:11 ... We want to get at the data directly and poll it. 20:49:34 ... We have a permission model, but often we want to get beyond that to the data and not have the permission model get in the way. 20:49:54 AR: We have an eventing model -- it's tuned for use on the markup/DOM 20:50:16 darobin: One issue with markup is that fallback with input type=location is a text field. 20:50:22 ... not a great way of entering data. 20:50:37 Josh_Soref: But not too bad. I'd rather paste into one text field. 20:51:11 AR: Form serialization algo. determins how to serialize the data without causing developers to do extra work. 20:51:25 darobin: If you get arbirary values instead of what you expect, it's not useful to the developer. 20:51:57 AR: Having a fallback doesn't mean that we hang everything off a single value property. 20:52:11 s/arbirary/arbitrary/ 20:52:15 darobin: Yes, but you end up doing just as much work by the developer. 20:52:30 i|Two contentions points|AR: Alex Russell (Google)| 20:52:39 Jim Steel (sensor platforms): Want to give my vendor perspective. 20:52:53 ... Sensors are tuned per the device. 20:52:54 Alex notes javascript on the wire is slow and punative 20:53:11 ... Developer would like to know what the sensors confidence degree is. 20:53:18 q? 20:53:21 q+ 20:53:26 darobin: Speaking to the Intents point... 20:53:39 ... Will happen in a joint TF between us and Web Apps. 20:53:51 s|Alex Russel (google): Two|AR: Two| 20:53:59 ... HR provided a great demo earlier. 20:54:17 ... before moving on with "should we do this with Intents", I'd like to see an example case. 20:54:21 i|give my vendor perspective|JimS: Jim Steel (sensor platforms)| 20:54:25 ... Can you provide such an exmaple? 20:54:28 Much thanks to Jose for demo and work on this 20:54:34 s/exmaple/example/ 20:54:45 s/Steel/Steele/ 20:54:51 s/Steel/Steele/ 20:55:11 Action: darobin to follow up with Alex Russell on getting an example of sensors on Intents. 20:55:11 Sorry, couldn't find user - darobin 20:55:53 s|Jim Steele (sensor platforms): Want|JimS: Want| 20:55:53 Action: berjon to follow up with Alex Russell on getting an example of sensors on Intents. 20:55:54 Created ACTION-464 - Follow up with Alex Russell on getting an example of sensors on Intents. [on Robin Berjon - due 2011-11-10]. 20:56:40 HR: If web devs don't get the data, they'll turn to other sources. 20:57:14 ISSUE: is low level data necessary for all sensor APIs, which ones have use cases and which not 20:57:14 Created ISSUE-122 - Is low level data necessary for all sensor APIs, which ones have use cases and which not ; please complete additional details at http://www.w3.org/2009/dap/track/issues/122/edit . 20:57:16 s/HR/Jose/G 20:57:22 darobin: Intents does sound like a potential contender 20:57:29 there's a typo in the Sensor API example, s/session/sensorConnection/ should fix it 20:57:42 Present+ Cullen_Jennings 20:58:18 Josh_Soref: Orientation was the one I noted that was so specific. 20:58:35 dowan has joined #dap 20:58:58 Action: jcantera to present use cases for the Sensors API 20:58:58 s/Jose:/jcantera:/G 20:58:59 Created ACTION-465 - Present use cases for the Sensors API [on Jose Manuel Cantera Fonseca - due 2011-11-10]. 20:59:28 Here is the link to web intents demo that Claes posted to the mailing list http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0009.html 20:59:34 ACTION-465: specifically use cases for need for raw lower level data, e.g. orientation 20:59:34 ACTION-465 Present use cases for the Sensors API notes added 20:59:57 Josh_Soref: If there's a requirement to get precision to 10 digits, and you right code that gets to 10 of the 10 digits, but my device only supports 6 digits, then my code might break. 21:00:17 s/right code/write code/ 21:00:21 darobin: sounds like folks that design websites to 1280 width and expecting it to work... 21:00:45 q+ to ask about agenda and webintents 21:00:56 q+ 21:00:58 Josh_Soref: I can still use a device as long as it doesn't refuse to work without the same precision as specified. 21:01:23 q? 21:01:27 q+ 21:01:30 ack robin 21:01:38 darobin: There's certainly a "don't be stupid" mentality that should be noted. 21:01:53 Suresh has joined #dap 21:02:14 darobin: Great job on the demo. This is a process that moves things forward. 21:02:30 ... There are lot of folks in the room that work on stuff like a WebOS... Would love their perspective. 21:02:34 q- 21:02:39 s/WebOS/Web OS/ 21:02:58 q- 21:03:23 sicking: I like the approach of having a low-level API. This proposal is good. I don't know enough about the other prior art, though it sounds like there's a lot of overlap. 21:03:32 ... I see good use cases for proximity sensors. 21:03:45 ... Ambient light sensors--not sure. Might want the OS to handle that. 21:03:49 +1 21:03:58 darobin: Might be done with a media query instead. 21:04:11 s/prior art/work/ 21:04:15 sicking: sounds like a good idea. 21:04:19 ... I like the idea of exposing this as an element, but don't know what it would look like. 21:04:56 ... proximity is a simple one that should just be exposed. Might just have two values -- proximiate or not. 21:05:12 s/proximiate/proximate/ 21:05:14 ... current spec is way more than what is likely needed. 21:05:17 ... interesting to experiment with this. 21:05:24 [Android is supposed to give you 0 or 1 for proximity; yet my Nexus reports "9" - go figure] 21:05:54 q+ 21:05:55 ... The UA might have trouble providing a notification for the use of such sensors. 21:06:02 privacy is certainly a concern with raw generic sensor API 21:06:12 dom: One point is that a security model is necessary depending on the type of sensor. 21:06:23 ... proximity... may not need security. 21:06:27 ... but some others may. 21:06:45 ... back to the question of whether a generic API is useful, or if specific APIs are needed. 21:06:45 (light probably does) 21:06:59 sicking: I like the idea of putting this in an extension and seeing what happens. 21:07:17 Are native apps using this kind of sensor data and if so what for? If there are some compelling use cases there we should take a look. 21:07:32 generic sensor api would likely affect fingerprinting in addition to revealing potentially sensitive sensor data 21:07:34 s/does/does need a security model/ 21:08:11 q? 21:08:14 AnssiK has joined #dap 21:08:21 richt: Sensors are kinda like services. How to connect to the sensor, get data from it... Security lies in the process of establishing a connection. 21:08:35 the ambient sensors and proximity are unlikely to have any privacy considerations as the information will be so random and constantly changing, that it would have very little value for fingerprinting 21:08:36 q? 21:08:55 darobin: Anyone else have an opinion? 21:09:00 there are things one can do w/ ambient 21:09:03 bryan, I mean that just knowing which combination of sensors are available on the device will enable fingerprinting 21:09:16 ... if there's a light flashing outside, it could be deciphered 21:09:44 So I wonder if we can reduce the security problem to one of 'connecting' to sensors and reducing the transmission problem to one of transmitting some data: json or otherwise. 21:10:12 ...which is why the Web Intents / Discovery angle is interesting here. 21:10:14 and native apps (like Color) have used otherwise 'random' ambient sensor values to determine whether one device is near another, which has substantial privacy concerns 21:10:34 acceleration and orientation are similar... I see very little privacy concern with these as they will also be largely random across a number of users 21:10:34 dom: There is interest in implementations, so that's positive progress. 21:10:35 -> http://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671/sourcecode?fileId=43517&pathId=1927408783 Accelerometer Sensor Sample from Microsoft Windows 8 Metro app 21:11:28 -> http://code.msdn.microsoft.com/windowsapps/Proximity-Sample-88129731 Proximity Sample from MS Windows 8 Metro 21:11:32 Scribe: Josh_Soref 21:11:43 bryan: wrt privacy 21:11:45 q+ 21:11:54 the probability that one user has an app that can access another user's sensors without opt-in 21:12:15 ...i can't see how you can get something which is so random across users 21:12:17 s/...i/... i/ 21:12:29 ... would someone trick someone into installing an app? 21:12:39 ... we need to focus on static attributes 21:12:47 q? 21:12:50 dom: sensors are privacy risks much beyond fingerprinting 21:13:00 ... gps are sensors 21:13:01 ack bryan 21:13:18 dom: you can payload a computer sitting nex to it 21:13:32 ... some sensors like proximity, you have less than others 21:13:37 Travis_MSFT: Link to information about Windows 8 Sensors access through JavaScript (API): http://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.sensors(v=VS.85).aspx 21:13:51 scribe: Travis_MSFT 21:14:12 +q Marcos 21:14:15 bryan: Still don't see significant privacy concerns 21:14:23 q? 21:14:25 dom: key point is that depending on the sensor, there's different privacy concerns. 21:14:28 ack fjh 21:14:28 fjh, you wanted to ask about agenda and webintents 21:14:29 ack fjh 21:14:44 fjh: I agree with Dom, but I think this is a bit premature given where we are. Somethings may yet change. 21:14:58 ... Thanks Jose, for all your work in the demo. 21:15:01 s/Dom/dom/ 21:15:32 I could go off the q and move fingerprinting discussion to email if chairs would prefer 21:15:39 q- 21:15:48 SungOk_You has joined #dap 21:15:55 ack npdoty 21:16:13 npdoty: working for team on privacy 21:16:16 ... Can't address the concern about not caring about privacy :) 21:16:39 ... my point on privacy: For a generic API, just "knowing" what is available is a risk 21:16:52 Anders has joined #dap 21:17:18 q+ 21:17:23 ack bryan 21:17:33 ... Plugins and Fonts have this problem, and introducing a new generic api for sensors will have a privacy concerns. 21:17:39 yu1 has joined #dap 21:18:01 q` 21:18:11 q+ 21:18:13 q+ sicking 21:18:27 ack sicking 21:18:33 s/q`// 21:18:50 ack sicking 21:19:23 Scribe: Josh_Soref 21:19:30 sicking: when we implemented Joystick 21:19:43 ... we don't expose Joystick to the web page 21:19:45 we have to be able to adapt to the device capabilities by knowing them, unless we are to require only one set of device capabilities on all devices 21:19:48 ... until the user uses the Joystick 21:19:53 https://wiki.mozilla.org/JoystickAPI 21:20:12 scribe: Travis_MSFT 21:20:21 q+ 21:20:27 shunan has joined #dap 21:20:29 ack bryan 21:20:43 bryan: sicking do you think we shouldn't support feature detection? 21:20:56 sicking: didn't say taht. 21:21:00 s/taht/that/ 21:21:03 ceyrigno has joined #dap 21:21:18 example from jonas is that you can know there is joystick but don't now brand and other details 21:21:28 sicking: We're adding joysticks, but are trying to do so without exposing a fingerprinting risk. 21:21:39 q+ 21:21:47 ack sicking 21:21:52 dom: two things: detecting the joysticks, and it's characteristics 21:22:00 s/it's/its/ 21:22:12 Cathy has joined #dap 21:22:15 sicking: It does put some limitations on the web developers. 21:22:46 ... could be done slightly better. But we should do things that are good. 21:23:02 bryan: I'd like to know whether the device supports front/back camera 21:23:19 sicking: the UA exposes that to the User, but the page doesn't know what the buttons are. 21:23:29 q? 21:23:31 ... buttons being the front/back 21:23:44 darobin: wrapping up on sensors discussion? 21:24:14 fjh: Jose did you have a followup action? 21:24:23 dsr__ has joined #dap 21:24:31 ... you took an action to get details on use cases for why we need a higher-level api 21:24:54 s/higher/lower/ 21:24:59 Jose: There's a slightly old draft. We have new feedback from implementations, etc., and need to update the draft. 21:25:13 ... including info from the mailing list. 21:25:13 ... those are the next steps. 21:25:17 actions? 21:25:29 darobin: such as doing a plugin for experimentation. 21:25:36 ... we also have the feedback from web intents. 21:25:41 ... lots of next steps :) 21:25:51 dom: schedule? 21:26:12 action: jcantera to update Sensor's API based on feedback, implementation etc 21:26:12 Created ACTION-466 - Update Sensor's API based on feedback, implementation etc [on Jose Manuel Cantera Fonseca - due 2011-11-10]. 21:26:28 darobin: I don't think we've looked deeply enough at web intents. 21:26:42 richt: If we use Intents, do we have to define the interface? 21:26:52 darobin: yes you still need to know how to get the data. 21:27:25 q+ 21:27:32 q- 21:27:36 richt: Intents allow us to make sensors more decentralized. You don't need to define all the formats, etc. up front. 21:28:19 fjh: We wanted implementor feedback...so, what's the timeframe for this? 21:28:49 sicking: I don't have a specific time. Development can take awhile. 21:28:50 ack fjh 21:28:59 sejinpark has joined #dap 21:29:01 ... I think proximity and ambient light should be exposed. 21:29:28 ... exposed via an API tailored to the experience. 21:30:12 action: dom to make proposal for proximity and ambient 21:30:12 Created ACTION-467 - make proposal for proximity and ambient [on Dominique Hazaël-Massieux - due 2011-11-10]. 21:30:19 (I think proximity would be better served by a simple "proximity" event) 21:30:26 dsr__: For ambient light, seems like a styling feature. Could be defined by CSS in media queries. 21:30:46 ACTION-467" ambient light 21:30:48 ACTION-467: ambient light 21:30:48 ACTION-467 make proposal for proximity and ambient notes added 21:30:50 s/ACTION-467* ambient light// 21:30:52 rrsagent, generate minutes 21:30:52 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 21:30:54 Marcos: Controls other actuators in the OS (dim the display, keyboard backlight) 21:31:11 dom: though you could consider expose those as well. 21:31:12 s/ACTION-467" ambient light// 21:31:14 darobin: Thanks again Jose. 21:31:19 Again thanks Jose 21:31:49 s/...Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/ 21:31:55 rrsagent, generate minutes 21:31:55 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 21:32:12 Jose: Referrig to discovery, the list sensors method opens the door to discovery if the implementation decides to. 21:32:13 s/though you could consider expose those as well/you could consider that keyboard backlight would be controlled by CSS in that case/ 21:32:22 ... Regarding extensility, I feel that it is extensible. 21:32:34 s/... Minutes from 26 October 2011/RESOLUTION: Minutes from 26 October 2011/ 21:32:53 dom: many of these things are still being explored. 21:32:58 rrsagent, generate minutes 21:32:58 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 21:33:20 topic: Messaging API 21:33:48 darobin: Using SMS, etc., to send messages. It's been significantly redesigned many times over. 21:33:54 ... Meh. 21:33:57 "meh-tality" 21:34:11 ... Some folks are starting to implement as it relates to Web OS. 21:34:13 q+ 21:34:24 ... Interested to know what implementors designs are looking like. 21:34:36 sicking: WebSMS prototype is almost done. 21:34:49 ... It's for SMS-only (not generic) 21:35:02 https://wiki.mozilla.org/WebAPI/WebSMS 21:35:50 ... This is an API that requires additional permissions. We wouldn't be comfortable simply saying "x page wants to send SMS". 21:35:58 ... haven't proposed it anywhere yet. 21:36:20 sicking notes security model not known yet, hence not deployed 21:36:23 darobin: in other places, security model parallels "mailto:" 21:36:43 [WebSMS still has SMSManager::send() though] 21:36:48 sicking: Now thinking of using sms: -based links (may needs a spec for that) 21:37:12 ... enum messages, delete messages, basic search, functionality 21:37:20 ... May never expose this to web pages. 21:37:45 darobin: my view of the security model might be... 21:38:12 q+ 21:38:18 ... some apps run in browser-context and can get some extra privelges, though sites may not get that priveledge. 21:38:27 +q marcos 21:38:43 sicking: Would be nice to have folks install their own SMS apps. 21:39:00 [FWIW, WebSMS looks closer to what we moved away from due to security concerns] 21:39:11 ... one security model is that the browser has a trust relationship with certain web stores. 21:39:20 ... stores may need to be EV certified. 21:39:39 ... problem with text message, is there's easy money to be made. 21:39:54 Kangchan has joined #dap 21:39:57 q+ spoussa 21:40:01 ... large incentive which influences the security model. 21:40:37 ... may also have an override for users, but behind non-accessible UI to prevent accidental use. 21:40:59 darobin: History: started with a powerful API, but trimmed due to security. Ended up with SMS: 21:41:12 s/SMS:/"sms:"/ 21:41:17 see http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#threats for premium rate abuse "abuse case" 21:41:23 Kihong_Kwon has joined #dap 21:41:25 q? 21:41:26 ... Current design allows you to add Blobs to an SMS. 21:41:50 fjh: In our policy use doc. We have documented abuse cases. 21:42:03 -q 21:42:03 -> http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#premium-rate-abuse Premium Rate Abuse in Policy Req documents 21:42:13 ack richt 21:42:21 richt: what's the use case for letting a web app manage my text messages? 21:42:35 there is an SMS uri scheme IETF draft (apologies if this is already well-known to the group) http://tools.ietf.org/html/draft-wilde-sms-uri-20 21:42:48 jgiraud has joined #dap 21:43:01 ... URL based SMS: has the option of giving the control back to the user. 21:43:12 ... not convinced that management of SMS is necessary. 21:43:20 ... Opera is not very interested at this stage. 21:43:42 q? 21:43:44 darobin: Often we're asked if we only do Web API or if we do APIs for other contexts. 21:43:49 youenn has joined #dap 21:43:51 ... usually we say "web apis" 21:43:52 q+ ndoty 21:44:11 sicking: We're not convinced that this should be a web api either. 21:44:11 RRSAgent, make minutes 21:44:11 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html ArtB 21:44:44 ack bryan 21:44:44 ... use case is that at least one app will need to manage SMS. Since we're building on Web Platform, we needed it. 21:45:33 [ http://en.wikipedia.org/wiki/Wholesale_Applications_Community - WAC ] 21:45:36 bryan: We have implemented trust models, etc., and have done a lot of work in this space; it's all be unravelled. Now, we could live with sms: 21:45:51 s/be/been/ 21:46:27 ... now we have devices who's OS is a web platform. If there can be pre-arranged trust relationships, we should go ahead and define what that should look like, or we accept fragmentation in the marketplace. 21:46:27 +q 21:46:30 q- npdoty 21:46:35 dom: charter is clear that we focus on web apis. 21:47:00 ... an API that can be implemented in a current web browser. 21:47:03 q? 21:47:12 -q 21:47:12 q? 21:47:13 q- ndoty 21:47:14 ack 21:47:19 q? 21:47:25 ack spoussa 21:47:30 s/ack// 21:47:51 spoussa: in the tyson project, we defined a lot of APIs around messaging. 21:48:00 Kepeng has joined #dap 21:48:12 s/tyson/tizen/ 21:48:13 ... hopefully we can come out and publish those soon. 21:48:29 Josh: but W3C will not be interested in that (since they're not Web APIs) 21:48:31 s/tyson/tizen 21:48:41 dom: we're talking about DAP (not W3C in general) 21:49:32 darobin: trying to do Web OS and Web APIs at the same time is problematic. So we stay stricly Web API-based. 21:49:50 ... If there's sufficient interest, talk to someone at W3C to start a group... 21:50:29 darobin: It sounds like we're keeping Web Messaging "on the shelf" 21:50:52 q+ 21:50:53 richt: I don't think the web messaging (sms) belongs on the ubiquitous Web. 21:50:55 q+ 21:50:56 q+ 21:50:57 q+ 21:51:02 q? 21:51:03 q+ to remind we have an existing api without sms management 21:51:11 I see a place for WebSMS but it's not on the ubiquitous web. 21:51:17 zakim, slap Josh_Soref to see if I can 21:51:17 I don't understand 'slap Josh_Soref to see if I can', fjh 21:51:30 rrsagent, slap Josh_Soref to see if I can 21:51:30 I'm logging. I don't understand 'slap Josh_Soref to see if I can', fjh. Try /msg RRSAgent help 21:51:45 sicking: At mozilla, we've worked on web intents, where the first use case is messaging (e.g., sharing) 21:52:14 very good point that our messaging API would probably be completely overtaken by Web Intents/Activities 21:52:14 ... user can choose which message channel they want to use, but to base that on Web Intents. 21:52:16 zakim, who is here? 21:52:16 On the phone I see tpac 21:52:17 On IRC I see Kepeng, youenn, jgiraud, Kihong_Kwon, Kangchan, dsr__, Cathy, ceyrigno, shunan, yu1, Anders, SungOk_You, AnssiK, Suresh, dowan, jcantera, Kai, jlebar, Soonho, linuz, 21:52:21 ... jun, Luca, slightlyoff, giuseppe, ArtB, fluffy, Travis_MSFT, ryoichi, Marcos, npdoty, dsr, DKA, nvbalaji, Mauro, JariA, bryan, richt, fjh, nwidell, kensaku, spoussa, lgombos, 21:52:25 abarsto has joined #dap 21:52:26 ... a12u, shan, jfmoy, ernesto_jimenez, marengo, sicking, mounir, dom, darobin, Zakim, RRSAgent, wmaslowski_, trackbot, ingmar, matt, ilkka, Josh_Soref 21:52:34 q? 21:52:40 ack sicking 21:52:52 darobin: makes sense to look at use cases. 21:53:21 jongyoul has joined #dap 21:53:34 darobin: Anything you can submit/send 21:53:44 ACTION: Robin to look as Mozilla Labs Sharing experimentation re Messaging API 21:53:44 Created ACTION-468 - Look as Mozilla Labs Sharing experimentation re Messaging API [on Robin Berjon - due 2011-11-10]. 21:54:18 q+ to ask how does Web Intents allow me to send an MMS? 21:54:22 q? 21:54:30 http://mozillalabs.com/blog/2011/10/firefox-share-alpha-%E2%80%94-the-next-step-for-fast-sharing-in-firefox/ 21:54:51 Suresh: regarding security model problems: have we documented the concerns so that we can try to work with/around them? 21:55:13 dom: we have one example in the policy document. 21:55:13 zakim, who is the most good looking? 21:55:13 I don't understand your question, Marcos. 21:55:19 see policy requirements draft on abuse cases 21:55:20 http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#premium-rate-abus 21:55:22 ack Suresh 21:55:44 richt: another concern is to put the sms technology into the web (we should do something more generic, not tied to the specific technology) 21:55:50 ack nicklas 21:55:54 ack nwidell 21:55:58 q- fjh 21:56:02 The Mozilla share intent is documented at http://webintents.org/share 21:56:16 s/Mozilla// 21:56:21 nwidell: mailto:++ is this something that we're also dropping, or is it solved by Web Intents. 21:56:39 darobin: It might be solved by Web Intents 21:56:40 jcdufourd has joined #dap 21:56:54 darobin: haven't heard lots of feedback desiring this... 21:56:57 JonathanJ has joined #dap 21:57:11 q? 21:57:14 q? 21:57:17 ack dom 21:57:17 dom, you wanted to remind we have an existing api without sms management 21:57:43 dom: if there is convergence on dropping web messaging in favor of Web Intents, are there any objections? 21:58:27 darobin: Any objections to updating the spec to indicate that it's not inprogress. 21:58:36 s/inprogress../in progress?/ 21:58:58 Jose: I object. You are sending the message that it's not usefull work. It's dangerous to say that. 21:59:02 darobin, this must be done. 21:59:11 ... you are sending that message (no pun) 21:59:20 q+ 21:59:46 ... I think SMS is a useful approach 21:59:57 dom: if you are saying we should document all good approaches... 21:59:58 q? 22:00:22 JariA has left #dap 22:00:33 darobin: we have lots of drafts out there, it leads to conclusion. 22:00:39 kensaku has joined #dap 22:00:42 q? 22:00:58 s/conclusion/confusion/ 22:01:40 ... other people pick up on our drafts. We want to clarify that "this spec" is not something that DAP is pursuing. 22:02:54 ... we put a note in the spec. We can finesse the wording. When we stop working on something, we need to be clear that we're not following that path. 22:02:55 q? 22:02:59 [FWIW, I think the current Messaging API wouldn't actually address most of jcantera's use cases] 22:03:03 ... let's find the wording that is acceptable. 22:03:22 ack bryan 22:03:22 bryan, you wanted to ask how does Web Intents allow me to send an MMS? 22:03:44 q- 22:03:58 AnssiK has joined #dap 22:04:21 bryan: Looks like a lot of stuff in our charter could merge together... How will Web Intents subsume this stuff? 22:04:32 ... I'd love to have an answer to this. 22:04:55 ... I'd suggest that we hold our decision on the messaging spec. 22:05:56 ACTION: Robin to make a CfC for shelving Messaging 22:05:56 Created ACTION-469 - Make a CfC for shelving Messaging [on Robin Berjon - due 2011-11-10]. 22:06:23 [Short Break] 22:06:34 RRSAgent, draft minutes 22:06:34 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html shan 22:06:34 RRSAgent, draft minutes 22:06:34 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 22:08:13 a1zu has joined #dap 22:14:45 jfmoy has joined #dap 22:21:54 helena has joined #dap 22:22:18 marengo has joined #dap 22:22:49 DavidKim has joined #dap 22:23:33 Marcos has joined #dap 22:24:13 dowan has joined #dap 22:24:36 nwidell has joined #dap 22:26:42 DavidKim has left #dap 22:26:50 DavidKim has joined #dap 22:32:25 helena has left #dap 22:33:15 spoussa has joined #dap 22:33:32 lgombos has joined #dap 22:35:35 Scribe: Josh_Soref 22:35:49 fjh: we should start again 22:36:03 Topic: DAP Architectural Issues 22:36:21 fjh: we've invited members of TAB 22:36:49 noah: Noah Mendelson, TAG Chair 22:36:51 richt has joined #dap 22:36:59 henry: Henry Thomson, U of Edinburg 22:37:11 JonathanJ1 has joined #DAP 22:37:12 peterl: Peter Lins, HP 22:37:20 s/TAB/TAG/ 22:37:29 plinss has joined #dap 22:37:30 noah has joined #dap 22:37:30 nwidell has joined #dap 22:37:49 s/Mendelson/Mendelsohn 22:37:56 s/peterl/plinss/ 22:38:02 s/Lins/Linss/ 22:38:20 PhilipG1 has joined #dap 22:38:38 a12u has joined #dap 22:38:43 present+ Philip_Gladstone 22:39:00 [ fjh presents: http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf ] 22:39:29 [ Slide "Approach" ] 22:39:53 fjh: we talked about using WebIDL and binding to HTTP 22:39:58 Youngsun has joined #dap 22:40:12 npdoty has joined #dap 22:40:15 [ Slides inputs re:Arch ] 22:40:15 s/Slides/Slide/ 22:40:31 fjh: Calendar could be Calendar on Web instead of on Device 22:40:38 ... we want to avoid having two definitions 22:40:48 a1zu has joined #dap 22:40:58 ... we could make WebIDL produce JS bindings 22:41:14 ... we decided in Prague that we wanted to explore this 22:41:18 ... and then we forgot about it 22:41:27 [ It came up again in Paris ] 22:41:36 [ Slide "Next Steps" ] 22:41:46 abarsto has joined #dap 22:41:55 fjh: things like Contacts says it could be local or remote in spec 22:42:01 ... but i'm not sure it says enough 22:42:13 ... should we seriously consider an http-webidl binding 22:42:22 ... then there's discovery (new to the WG, after Recharter) 22:42:28 s/discovery/Discovery/ 22:42:47 fjh: Security and Privacy are a bit different 22:43:11 ... are we ok w/ doing what we're doing - JS w/ WebIDL 22:43:11 ... we don't want to rework 22:43:19 ... can we get an approach that satisfies other requirements 22:43:32 ... I have a separate topic on Privacy, for later 22:43:36 abarsto has joined #dap 22:43:41 ... for now, do we need to do something specific for resources on the web 22:43:44 ... if so, how? 22:43:56 [ End of Slides ] 22:44:31 X1: where are you on timeline? 22:44:35 darobin: we're not very advanced 22:44:42 ... we have some minimal research 22:45:23 ... it was contentious and we found a way of not committing 22:45:35 ... if someone comes with something either way, it would sway the balance 22:45:55 ... initial feedback was ReSTful 22:46:16 ... it initially surfaced that unless you constrained WebIDL 22:46:17 ... it quickly becomes JSON RPC 22:46:19 q+ 22:46:22 ... http based, but not ReST 22:46:33 noah: I wonder if you're overconstraining the answers 22:46:42 ... assuming that the right thing is the IDL 22:46:49 ... and focus more on wire 22:47:02 ... because it tends to lead you to SOAP like 22:47:14 ... JS is capable of very fine grained 22:47:19 ... i wonder if the right thing is to say "some things are ReST" 22:47:26 ... and documented in "WADL" 22:47:32 ... and some things are JS 22:47:38 jgiraud has joined #dap 22:47:43 ... "course grained streaming operations" 22:47:54 ... you could imagine a JS based api to the camera that let you pull bits out if you want to 22:47:58 Kai has joined #dap 22:48:02 ... whereas with ReST you'll want a streaming thing 22:48:27 q+ 22:48:57 i|Edinburg|ashok: Ashok Malhotra, Oracle| 22:49:11 s/X1/ashok/ 22:49:24 noah: it feels like a Calendar based API 22:49:35 ... in ReST, something would stream back 22:49:43 ... saying you'll start with JS based 22:49:49 ... you'll get something different 22:49:59 fjh: what about URIs 22:50:13 ... and what about data minimization 22:50:19 darobin: there's a conflict between minimization and ReST 22:50:30 ... but there's a problem involving URIs giving different output 22:50:40 noah: if you're going after someone's calendar through an HTTP link 22:50:45 ... you don't want to do 10 GETs 22:50:55 ... maybe you create a more complicated HTTP uri 22:50:56 Frederick, the links in your slides don't work. Can you put them into IRC? 22:51:34 plinss: if you ignore that now 22:51:42 ... you'll design things that will never work with ReST 22:51:47 noah: my prejudice will be 22:51:57 ... there are certain tangible benefits of URIs 22:52:02 ... and accessing via ReST 22:52:14 ... - if you have a Camera on a machine 22:52:17 ... and you can access it remotely 22:52:30 ... When you name things with URIs that support http 22:52:36 ... you can access it transparently 22:52:45 ... there are times when our little devices want to act as servers 22:52:51 ... if you're a semantic web person 22:52:59 ... the very fact that you can name it with URIs is useful 22:53:11 ... saying this is broken 22:53:34 rrsagent, draft minutes 22:53:34 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html JonathanJ1 22:53:34 ... there are pieces you can access with uri's that you can't with JS 22:53:43 fjh: sicking thoughts? 22:54:02 sicking: if you access with a URI, what's the security model? 22:54:14 darobin: there's important background 22:54:17 ... initially this was tied to WebIntroducer 22:54:25 ... which is a way of introducing a service to another 22:54:25 http://www.w3.org/2009/dap/wiki/images/3/38/Dap-architecture-status.pdf 22:54:28 Present+ Jonathan_Jeon 22:54:34 ... and what you get is an http endpoint 22:54:41 ... which is opaque 22:54:54 q? 22:54:59 ... the user was asked to provide a relationship 22:55:11 ... and you get a version which opaquely describes the thing the user chose 22:55:21 ... WebIntroducer faded and is replaced by WebIntents 22:55:33 ... this change makes http things less attractive for us 22:55:48 Marcos: you're talking about WebIntents like it's a sure thing 22:55:49 linuz has joined #dap 22:55:55 darobin: it indeed isn't 22:56:12 ... but the way things are headed, Mozilla Activities don't give you a URI either 22:56:13 DKA has joined #dap 22:56:16 jcdufourd has joined #dap 22:56:20 ... it seems like mozilla's list is moving away from user mediation 22:56:24 present+ Daniel_Appelquist 22:56:25 ... and closer toward web workers 22:56:31 ... with things thrown over the wall 22:56:46 noah: in general, identification should be orthogonal to ACL 22:56:58 ... that not everyone should be able to get at my plane reservation 22:57:11 ... isn't a reason for it not to be on the web 22:57:23 ... don't put credential granters / privacy violations into the url itself 22:57:39 ... but do have ACLs so that the wrong people can't access the content of a URI 22:57:52 -> http://www.w3.org/TR/webarch/#id-access Linking and access control in the WWW Architecture Document 22:57:53 ... saying we need Access Control isn't a reason not to use URIs 22:57:59 sicking: I see the point of ACL 22:58:11 s|ACL|Access Control|G 22:58:13 q? 22:58:47 sicking: that you can't send a URI to your vendor because they can't access it 22:59:14 noah: putting credentials into a uri (like Google Docs) is controversial 22:59:14 ... but even if they're separate 22:59:19 ... maybe i identify myself as "noah" 22:59:34 ... it doesn't mean i shouldn't be able to have someone send me the uri to their camera 22:59:52 ... and i access it with my identity and see their "snow-fall" 22:59:59 fjh: Battery is moving along 23:00:16 ... and there's no reason for it to be ReSTful' 23:00:16 s/'// 23:00:23 ... similarly, vibrator doesn't need to be ReSTful 23:00:45 noah: i remember 30 years ago that Printer vendors looked puzzled when asked about Web Servers on them 23:00:55 kensaku has joined #dap 23:01:14 q? 23:01:17 ... and today i can talk to an average printer over HTTP 23:01:32 fjh: so, "it could be handy to ask it over the web?" 23:01:41 noah: i'm saying weigh the costs, 23:01:47 ... and consider possible uses/benefits 23:01:55 ... and maybe if there's some benefit, maybe it should be done 23:02:10 I'm in complete agreement with Noah, btw. 23:02:11 fjh: what if we said "ReST is v2?" 23:02:19 Marcos: it has to be based on Use Cases 23:02:30 ... noah's example is great 23:02:43 ... the gemalto people are running servers on Smart Cards 23:03:11 ack bryan 23:03:14 q- 23:03:15 well, I say "complete agreement". I think I'm in agreement but I missed some of the conversation. 23:03:29 Marcos: there are really cool things you can do w/ ReST 23:03:40 noah: and i think there are cases where it's a really stupid idea 23:03:48 q+ 23:03:52 ... like access to the screen buffer or cpu with GET/POST 23:03:55 kensaku_ has joined #dap 23:04:00 Are device-local resources to be considered equal in terms of value to cloud-based resources? Is there a difference in trust for the user? Do I trust a cloud-based service any more than I trust the device in my hands, or the Web server via which I accessed the app that wants to access the information on the device in my hands? 23:04:13 i|resources|bryan: questions re:Arch on web| 23:04:15 q- 23:04:45 bryan: if i went to a web page, do i trust it less than i trust something in the cloud? 23:04:58 If we were to use REST for access to device-local resources, is there any difference to accessing remote resources? If I have a URI to a camera (local or remote), how does the browser ensure the camera owner authorizes the use of that camera? 23:05:00 ... that determines whether or not we consider the device to be part of the web 23:05:24 ht has joined #dap 23:05:37 zakim, q 23:05:37 I don't understand 'q', ht 23:05:41 zakim, q? 23:05:41 I see no one on the speaker queue 23:05:41 q? 23:05:43 Note - issue with REST interface for DAP APIs might be minimization 23:05:45 q? 23:06:12 q+ 23:06:12 Q- 23:06:13 q? 23:06:15 q+ to argue for a minimalist position 23:06:33 s/henry:/ht:/ 23:06:56 ht: if you think that a device is implicitly on the web 23:07:12 ... - each of these things is a little web server 23:07:13 ... changes the balance of power 23:07:19 ... in a way that i don't think you want to go to right now 23:07:27 ... the benefits that noah was talking about 23:07:40 ... arises if the device is addressible 23:07:59 ... for the forseeable future, they won't be addressible 23:08:16 +.5 to henry 23:08:19 ... that you want to have access from any server on the web to any device on the web 23:08:26 ... given the scale of the task in front of you 23:08:39 ... i think you'd be entirely justified to say Device APIs are for the Device 23:08:53 ... plinss 's right, if you do this, then it'll be awkward later at best 23:09:01 q? 23:09:11 noah: I asked you to think about it, and you did 23:09:13 q- ht 23:09:13 q+ 23:09:15 Wonsuk has joined #dap 23:09:23 dsr__: in many cases, JS makes sense 23:09:30 ... sometimes ReSTful apis make sense 23:09:35 ... but it involves looking at UCs 23:09:40 q+ 23:09:48 fjh: i'm concerned, W3C is talking about going `fast` 23:09:57 plinss: I like bryan 's point about trust 23:10:14 ... there are States where if you get pulled over for a Traffic Stop 23:10:23 ... the police have the right to plug something into your device 23:10:29 ... i'd like the device to be able to not trust that 23:10:32 s/then it'll/then in a few cases it'll/ 23:10:38 ... i accept there's a pragmatic approach 23:10:45 ... maybe not making the battery available 23:10:46 q? 23:10:55 ack bryan 23:11:02 ... think about "were i to access this over http, what would my access pattern be?" 23:11:14 ... such that you could design an api to insert to support that 23:11:18 ... maybe the local code doesn't change 23:11:36 ... you don't have to write that with the mechanism today 23:11:45 ... but you're taken care of later by using that bit in a Constructor 23:11:49 If my device has an access point it has exposed, e.g. for a service as envisoned by Web and TV IG, or a camera, should a local app be given less permission than a remote app, or are they equal given user permission for them to access the local resource? 23:12:12 npdoty has joined #dap 23:12:33 bryan: Discovery of devices in the home... 23:12:41 peter gave example of abuse case of local data, having law enforcement obtain information from device when that isn't appropriate because it is local 23:13:12 q? 23:13:26 bryan: if a user has given permission, why shouldn't an app be able to access the resource? 23:13:26 q? 23:13:27 ack sicking 23:13:35 sicking: trust issues 23:13:43 ... even if we do v1 in JS 23:13:47 ... and v2 which is http based 23:13:52 Marcos has joined #dap 23:14:15 ... even if we knew we were going ReSTful 23:14:21 +1 to bryan -- architecting and installing the necessary security/authentication story for arbitrary devices on the web is not straightforward -- but presumably web-of-things has this in view. . . 23:14:23 ... i don't know i'd want web developers to fire 10 http calls just to communicate with Contacts 23:14:28 ... sure we could wrap jQuery around that 23:14:31 RRSAgent, make minutes 23:14:31 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html ArtB 23:14:42 ... but we'd want to make sure one wraps the other 23:14:43 q+ to ask about TAG review 23:14:49 ... one more understandable and simple 23:14:56 ack fjh 23:14:56 fjh, you wanted to ask about TAG review 23:15:12 Present+ Kangchan_Lee 23:15:12 plinss: you could design the ReSTful, and design the JS, and not implement one 23:15:20 ... you could get it wrong 23:15:33 noah: you could run into a risk where the two aren't equivalent and if you use both... 23:15:44 ... in retrospect, we like controlling printers from browsers 23:15:47 ... sometimes remotely 23:15:55 ... if you can get 60% done w/ js 23:16:00 ... then people will forget the rest 23:16:12 ... that's the bigger risk, but i don't know how to quantify 23:16:19 ... it seems like for most of this, you're committed to JS 23:16:35 ... maybe for some you should survey things and see if some of them where there are UCs for ReST 23:16:45 ... and if some seem useful now/real soon 23:16:52 fjh: my sense is we should stick w/ JS apis 23:16:54 TAG: Opera is looking in to the HTTP approach to local devices. You might want to look at: http://people.opera.com/richt/release/specs/discovery/Overview.html 23:17:03 ... UCs that would help us 23:17:13 ... maybe the tag could help us 23:17:13 ... by reviewing one of our specs 23:17:22 ... i think maybe Contacts is the only one 23:17:27 ... but i'm so concerned about minimization 23:17:37 noah: is Contacts private to a device? 23:17:45 darobin: when mozilla labs 23:17:55 ... did it, it could also expose arbitrary remote contacts 23:18:01 noah: look at Email 23:18:11 ... hypothetically in Gmail, there is a uri for each email 23:18:12 s/we should stick/that the rough consensus of the Working Group is that we should stick/ 23:18:23 [HTTP isn't a good fit when the service needs to send asynchronous messages to the client] 23:18:25 ... imagine the URI was portable from my device to my phone 23:18:35 s/only one/one 23:18:40 Josh_Soref: Gmail doesn't do that, it has a different URI or different device styles 23:18:57 noah: maybe things have a URI, and maybe it can be resolved locally 23:19:11 dsr__, Server SEnt Events make asynchronous messages fairly easy via HTTP 23:19:11 ... maybe you're replicating your Picasa/Flickr photos 23:19:20 ... i'd like them to have the same URIs on Phone and Flickr 23:19:30 ... except when you want to reference the replica 23:19:42 ... you may say that integrating address books with too much history 23:19:46 ... that it's too hard to wrap 23:19:48 q? 23:19:51 q+ 23:20:11 q? 23:20:21 richt: We, Opera, have been working on Device APIs for a long time 23:20:30 ... the URL is the killer feature of the web 23:20:35 ... and accessing stuff via http 23:20:39 ... not just ReST 23:20:44 ... accessing data 23:20:50 ... we;re interested in that approach 23:21:00 s/we;re/we're/ 23:21:11 ... it's local, but it's on the web as well 23:21:15 fjh: this is a Discovery protocol 23:21:29 ... but it doesn't address minimization, or contacts 23:21:36 ... it's up to the service/services that provide them 23:21:50 ... everything's addressable with http 23:22:12 addressable via URI does not equate to only accessible via HTTP 23:22:15 s/fjh: it's up to the/richt: it's up to the/ 23:22:21 like X-Archived-At email headers? 23:22:31 s/fjh: everything's/richt: everything's/ 23:22:49 fjh: maybe we should move on?? 23:22:50 ack Josh_Soref 23:22:55 s/??/?/ 23:23:18 ScribeNick: fjh 23:23:45 Josh_Soref: contact merging, integration of local and non-local should be transparent to user 23:23:58 ... JavaScript API we have does not prevent that 23:24:15 ... ndoty mentioned X-Archived-At email headers, we need that 23:24:32 ... need something like UUID but not UUIDs 23:24:39 ... merged URLs don't work 23:25:13 ... W3 mailing list system is smart about URLs for cross-posted messages, allowing selection 23:25:37 ... URL for picture might be picture1 23:25:50 ... need really long URLs for local pictures to make unique on the web 23:26:11 ... also bad for privacy since this means URL is disclosing information 23:26:18 or a form of fingerprinting 23:26:45 Josh_Soref: bad urls can be a problem 23:27:56 q? 23:28:00 I think Josh is questioning universal object addressability via URI 23:28:16 q? 23:28:47 PhilipG has joined #dap 23:29:40 [ fjh's email said: Also linked to DAP agenda at http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC) ] 23:29:49 RRSAgent, draft minutes 23:29:49 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 23:30:13 dom: maybe we prefer focusing on js for basic operations 23:30:13 ... i don't see value taking a resolution on this 23:30:16 q+ 23:30:18 proposed RESOLUTION: WG consensus to continue Javascript approach to existing APIs 23:30:21 richt: the proposal we have is a JS api 23:30:38 ... it may provide this function, it may swallow the other apis eventually 23:30:46 ... there's no harm in doing both approaches 23:30:55 fjh: i think we need a decision so we don't go around in circles 23:31:02 ht: a double negative solution 23:31:14 ... we decide: 23:31:20 ... we will not hold up a row in this table for lack of a ReSTful api 23:31:46 noah: a proposal 23:31:55 ... imagine we go down the road of doing JS apis 23:32:00 ... not really ReSTful 23:32:02 proposed RESOLUTION: will not stop current work for lack of a a RESTful API for that API 23:32:13 ... but where we need to identify something, 23:32:17 s/a a/a/ 23:32:28 ... we try to provide a URI for it 23:32:40 ... it may always be localhost today 23:32:56 ... but down the road, when we want to use a non local thing 23:32:57 proposed RESOLUTION: will not stop work on a current JavaScript API for lack of a a RESTful API for that API, 23:33:03 ... we can change the host 23:33:13 s/a a/a/ 23:33:21 (the actual resolution we could make would be to remove "REST-ful compatiblity" from our APIchecklist but it was already removed in May http://www.w3.org/2009/dap/wiki/ApiCheckList ) 23:33:30 ... and then it can be used in ReSTful 23:33:37 ISSUE-118? 23:33:37 ISSUE-118 -- How would feature discovery work for REST APIs -- open 23:33:37 http://www.w3.org/2009/dap/track/issues/118 23:33:51 proposed RESOLUTION: close ISSUE-118 23:34:27 Feature Discovery for REST APIs sounds like SOAP :( 23:35:12 Josh_Soref: there's a risk with constant uri's being abbreviated and misunderstood by developers 23:35:18 ... such that in the future when they're not changed, they fall apart 23:35:32 RESOLUTION: close ISSUE-118 23:35:40 close ISSUE-118 23:35:40 ISSUE-118 How would feature discovery work for REST APIs closed 23:35:53 RESOLUTION: will not stop work on a current JavaScript API for lack of a RESTful API for that API 23:35:55 close ACTION-442 23:35:55 ACTION-442 Produce a REST binding example for Contacts (client, server, protocol) closed 23:36:11 Topic: Privacy 23:36:23 fjh: this group has done two things 23:36:34 .... one is minimization 23:36:39 s/..../.../ 23:36:51 ... the other is implicit consent 23:37:21 ... there's work in the EU on privacy 23:37:41 http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0091.html 23:37:59 fjh: executive summary 23:38:16 ... consent is not just "i said share these 3 contacts is consent" 23:38:24 ... it has to be informed consent 23:38:35 ... you have to know what's going to happen to that information 23:38:38 ... for what purpose 23:38:48 ... how long will it be retained, how will it be used? 23:38:52 ... the other aspect 23:39:12 ... is it isn't within the API scope to define what third parties will do with that information 23:39:13 ... we have a system for privacy 23:39:21 ... it isn't a giblet 23:39:36 ... EU says you don't need to click on ok 23:39:46 I wouldn't conflate this stuff together. 23:39:47 q+ to talk about "we" 23:40:02 fjh: concerns: 23:40:13 ... active consent is optional 23:40:13 I mean API authorization and fjh's description of consent. 23:40:25 ... we're leaving it up to the web page to provide what's needed 23:40:35 ... - i don't know if it would be viable if it isn't 23:40:46 q? 23:40:58 richt: API auth isn't the same as consent 23:40:59 q+ 23:41:14 ... it's other stuff on the web site 23:41:19 fjh: we've been telling people we build in privacy by design 23:41:24 ... by having users take actions 23:41:31 ... which is insufficient according to EU opinion 23:41:38 dom: this is a systemic approach 23:41:44 ... but for consent to be informed 23:41:49 ... is not this group's problem 23:41:55 ... it's the problem of the provider 23:42:00 s/provider/site/ 23:42:11 ... i don't think that affects how we design the api 23:42:18 +1 dom. 23:42:18 ... we have consent 23:42:30 ... but i don't know that we need it for EU 23:42:31 +1 23:42:44 q+ 23:42:44 fjh: do we need consent UI to be mandatory? 23:43:03 dom: it's optional because UI is in a much larger framework than what we as a WG can usefully document 23:43:14 fjh: it's a can of worms, maybe we need to update Best Practices 23:43:16 q- 23:43:20 q? 23:43:23 q- 23:43:23 q- noah 23:43:40 npdoty: some experience from the GeoLoc case 23:43:47 ... i don't know if everyone was present 23:43:58 ... we agreed it would be good for End Users of GeoLoc to have informed consent 23:44:11 ... there was a large debate whether the protocol should enable informed consent 23:44:18 ... the controversial decision we made 23:44:22 ... was to leave it out 23:44:33 ... but put in a requirement on web sites 23:44:39 ... to use existing html 23:44:52 q- 23:44:55 ... UC Berkeley did a survey, and no one did it 23:45:13 ... you might think about the implications 23:45:16 q+ 23:45:17 -> http://escholarship.org/uc/item/0rp834wf Privacy Issues of the W3C Geolocation API 23:45:19 q+ to note that this may be beyond the API itself, e.g. the browser may be able to provide a button to view the site's privacy policy 23:45:22 ... there might be ways for the browser to facilitate communication 23:45:27 q+ 23:45:34 ... perhaps the browser could force web sites to do things 23:45:38 q- 23:45:39 ack npdoty 23:45:42 ack ernesto_jimenez 23:45:48 ACTION: fjh to update web application privacy best practices related to active consent 23:45:48 Created ACTION-470 - Update web application privacy best practices related to active consent [on Frederick Hirsch - due 2011-11-10]. 23:45:52 ernesto_jimenez: the fact that web sites "inform the user" 23:46:00 ... by adding a field to the user 23:46:11 q+ 23:46:12 ... doesn't mean they'll fill it in properly 23:46:22 ... providing another field will probably restrict what the UA can do 23:46:28 ... because it will probably have to show that 23:46:42 npdoty: In GeoLoc, putting this in would enable web sites to lie 23:46:50 ... there's no guarantee that it would be useful 23:46:51 websites will lie :) 23:46:59 ... but it could be a convenient way to provide info to users 23:47:20 ack dsr 23:47:20 dsr, you wanted to note that this may be beyond the API itself, e.g. the browser may be able to provide a button to view the site's privacy policy 23:47:21 ack dsr 23:47:21 ernesto_jimenez: someone will argue that the Browser telling the User what the User said, that the user will trust the Web Site 23:47:31 q+ to note that browsers are improving this by making Content Alerts 23:47:52 dsr: in some cases it can be the responsibility of the browser to provide e.g. a link to a privacy policy 23:47:59 ... it might not require changing the api 23:47:59 ack bryan 23:48:11 The browser chrome needs to provide a means for users to easily see the types of personal data that the website can access. This is analogous to what is provided by native app managers (though not in the direct context of the app running, as usually the case). 23:48:58 bryan: if the browser had a "what this page can do" 23:49:14 s/what the User said/what the User Agent said/ 23:49:16 ... just like native app managers 23:49:31 ... users can back away, or uninstall 23:49:39 ... in our studies, "users don't care" 23:49:49 ... providing prompts doesn't enhance the user experience 23:49:50 q? 23:49:56 [I worked on something like that with a Firefox extension - Privacy Dashboard http://code.w3.org/privacy-dashboard ] 23:49:59 ack fjh 23:50:00 s/will trust the Web Site/will be more likely to trust the Web Site because they trust what they user says/ 23:50:11 fjh: we punted on rulesets 23:50:21 ... which enabled users to say what they expected wrt privacy server side 23:50:24 ... i think dsr is right 23:50:28 -> http://dev.w3.org/2009/dap/privacy-rulesets/ Privacy Rulesets Proposal 23:50:38 ... it seems like we could provide access to a Privacy URI 23:50:40 q+ 23:50:49 ... it's not the best thing 23:51:01 dom: is that at the api level? 23:51:13 ... or is it just a link for privacy? 23:51:16 fjh: maybe not 23:51:24 ... but is there anything for privacy by design we could push for 23:51:35 ... beyond what is in our scope 23:51:42 our paper on Privacy Issues of the W3C Geolocation API: http://escholarship.org/uc/item/0rp834wf 23:51:43 noah: do you specify at that level? 23:51:51 ... you could have things which don't have e.g. buttons 23:52:01 fjh: we could suggest "provide a means to convey a uri" 23:52:23 s/convey a uri/convey a uri for privacy notice/ 23:52:38 q? 23:52:48 ack Josh_Soref 23:52:48 Josh_Soref, you wanted to note that browsers are improving this by making Content Alerts 23:53:18 Josh_Soref: users trust browsers more than web pages 23:53:31 ... alerts were anchored to browser, looked as if from browser 23:53:40 ... now switching so they look like part of the page 23:53:55 ... so browsers can show material from page without confusion 23:54:20 q? 23:54:28 ack ernesto 23:54:32 noah: the fact that Users actually trust the Browser is interesting 23:54:32 q+ 23:54:49 ernesto_jimenez: the concern that we need to do Privacy by Design 23:54:54 ... that the browser must get consent 23:55:01 ... but then the browser should inform the user 23:55:11 fjh: Privacy by Design is Privacy by Default 23:55:15 Kai has joined #dap 23:55:20 ernesto_jimenez: but Privacy/Security is for each one of us 23:55:29 ... the UA asks for information 23:55:33 q? 23:55:34 q+ 23:55:36 ... and it has to account for that 23:55:43 ack npdoty 23:55:48 npdoty: that's an excellent point 23:55:58 ... the work out of this group has been excellent 23:56:11 ... informed consent is an indication of dialog between the site and the user 23:56:20 ... if a UA might want to make a privacy preserving impl 23:56:26 ... they might want to have this extra field 23:56:38 q? 23:56:43 ... defining it in the api or otherwise standardizing this communication protocol 23:56:46 q+ for point of order 23:56:51 dowan has joined #dap 23:56:55 ... that's why i want to discuss it at the api level 23:57:12 ernesto_jimenez: if UA vendors ask for this 23:57:12 ... we could add it 23:57:36 ... but in these cases, trying explain what a page will do with info is tricky 23:57:40 ack nwidell 23:57:49 nwidell: we did some testing w/ normal users for getUserMedia() 23:57:57 ... what we found was that people trusted the web site 23:58:03 ... and they didn't understand 23:58:16 ... they trusted the web site 23:58:16 ... because it's a brand they interacted the most 23:58:57 ... your user in the street doesn't understand the bit about UAs 23:59:12 ... no matter how much we try to build sophisticated chrome around this 23:59:18 ... it might not solve the problem, because users might not see these things 23:59:24 [ time check ] 23:59:37 ernesto_jimenez, websites will lie and if anyone wants to do UI/UX research we're happy to read it :) 00:00:24 We know that web sites will lie, but it is hard to communicate that to users 00:00:57 [ fjh tries to summarize ] 00:00:57 http://www.w3.org/2011/04/webrtc/wiki/File:Webrtc_privacy.pdf 00:01:12 i|www.w3|Topic: Security 00:02:11 darobin: I was in the WebRTC WG 00:02:30 ... and it seemed like they didn't know what we'd done in the area 00:02:34 we have actually documented some of it in http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/ afaik 00:02:42 richt: we've had this principle which has informed our design 00:03:14 ... Opera and Mozilla did hundreds of hours of work and reached the same conclusion/design 00:03:19 s/fjh tries to summarize/Summary - our "implicit consent" mechanism is consistent with "active consent" but requires web applications to provide notice, the WG may consider whether conveying notice should be done by more than relying on a web page to include that information 00:03:23 rrsagent, generate minutes 00:03:23 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 00:04:11 darobin: it would have been simpler if we had a 2 page document we could point to 00:04:24 ... since you [WebRTC] aren't the last WG who will need to work in this space 00:04:34 ... some of this is in our Wiki in the API checklist 00:04:40 fluffy: Cullin Jennings, Cisco 00:04:44 higher level principles and examples would both be great 00:04:47 fluffy: something like that would help 00:04:59 darobin: (a) documenting it (b) removing confusion that it isn't done 00:05:16 dom: we have a document 00:05:22 we also have http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/ 00:05:25 ... - the privacy document 00:05:30 I would note that the Privacy and Security Interest Groups would be very interested, for example 00:05:35 darobin: but having a note on security principles for api design 00:06:14 ACTION berjon to look into a document for Security Principles for API Design 00:06:14 Created ACTION-471 - Look into a document for Security Principles for API Design [on Robin Berjon - due 2011-11-11]. 00:06:33 npdoty: that would be awesome 00:06:39 Topic: AOB 00:06:45 Topic: Tomorrow 00:06:50 darobin: Discovery API 00:06:52 action: fjh to update policy requirements for security requirements 00:06:52 Created ACTION-472 - Update policy requirements for security requirements [on Frederick Hirsch - due 2011-11-11]. 00:06:58 [ Adjourned ] 00:07:12 RRSAgent, draft minutes 00:07:12 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 00:07:12 RRSAgent, make minutes 00:07:12 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 00:07:43 ACTION: Robin to coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note 00:07:43 Created ACTION-473 - Coordinate with fjh on the production of a "General Security Principles in Web APIs Design" Note [on Robin Berjon - due 2011-11-11]. 00:08:14 s/Cullin/Cullen/ 00:08:21 RRSAgent, make minutes 00:08:21 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html Josh_Soref 00:08:30 fluffy has left #dap 00:11:22 DavidKim has left #dap 00:15:23 a12u has joined #dap 00:19:56 giuseppe has left #dap 00:32:01 disconnecting the lone participant, tpac, in Team_(dap)17:47Z 00:32:03 Team_(dap)17:47Z has ended 00:32:06 Attendees were tpac, jlebar 00:33:25 jlebar has left #dap 00:34:39 ht_home has joined #dap 00:36:09 fjh has joined #dap 00:49:02 Marcos has joined #dap 01:01:41 Kangchan has joined #dap 01:05:13 Kangchan has left #dap 01:24:52 sejinpark has joined #dap 01:35:08 kensaku has joined #dap 01:39:11 Marcos has joined #dap 01:48:03 kensaku has joined #dap 01:50:29 Kangchan has joined #dap 01:50:57 Kangchan has left #dap 01:53:48 kensaku has joined #dap 01:58:11 kensaku has joined #dap 02:00:56 kensaku has joined #dap 02:05:39 spoussa has joined #dap 02:06:35 Zakim has left #dap 03:15:28 kensaku has joined #dap 03:41:32 sriramyadavalli has joined #dap 03:56:41 fjh has joined #dap 04:00:01 giuseppe has joined #dap 04:00:10 giuseppe has left #dap 04:00:10 noah has joined #dap 04:09:34 plinss has joined #dap 04:20:26 kensaku has joined #dap 04:22:59 plinss has joined #dap 04:35:37 sicking has joined #dap 06:08:09 Frankie has joined #dap 06:08:11 Marcos has joined #dap 06:53:34 fjh has joined #dap 07:26:13 Marcos has joined #dap 07:29:11 wmaslowski_ has left #dap 07:43:53 plinss has joined #dap 07:44:23 kensaku has joined #dap 07:54:25 sejinpark has joined #dap 09:54:33 wmaslowski has joined #dap 09:54:36 wmaslowski has left #dap 11:55:56 Frankie has joined #dap 13:14:48 ht has joined #dap 13:31:17 ht_home has joined #dap 13:36:38 ernesto_jimenez has joined #dap 14:33:50 tmpsantos has joined #dap 14:37:19 plinss has joined #dap 14:51:58 Frankie has joined #dap 15:08:34 nwidell has joined #dap 15:12:32 spoussa has joined #dap 15:18:38 Kai has joined #dap 15:30:41 Kangchan has joined #dap 15:33:45 noah has joined #dap 15:36:16 shan has joined #dap 15:36:26 AnssiK has joined #dap 15:37:54 ernesto_jimenez has joined #dap 15:40:13 lgombos has joined #dap 15:47:16 MattH has joined #dap 15:49:17 abarsto has joined #dap 15:49:28 Frankie has joined #dap 15:53:50 jun has joined #dap 15:54:23 plinss has joined #dap 15:54:51 plinss has left #dap 15:57:39 fjh has joined #dap 15:58:16 darobin has joined #dap 16:00:02 bryan has joined #dap 16:00:02 nwidell has joined #dap 16:00:17 Anders has joined #dap 16:00:23 vgalindo has joined #dap 16:00:28 olivier has joined #dap 16:00:38 Present+ Anders_Isberg 16:01:38 Present+ Virginie_Galindo 16:01:41 Present+ Ernesto_Jimenez 16:01:56 fjh has joined #dap 16:02:14 present+ Bryan_Sullivan 16:02:26 trackbot, start telecon 16:02:28 RRSAgent, make logs world 16:02:28 Zakim has joined #dap 16:02:30 Zakim, this will be DAP 16:02:30 I do not see a conference matching that name scheduled within the next hour, trackbot 16:02:31 Meeting: Device APIs Working Group Teleconference 16:02:31 Date: 04 November 2011 16:02:55 ht has joined #dap 16:03:03 SungOk_You has joined #dap 16:03:11 RRSAgent, this meeting spans midnight 16:03:12 fluffy has joined #dap 16:03:13 ht has left #dap 16:03:15 jgiraud has joined #dap 16:03:22 a12u has joined #dap 16:03:23 Present+ SungOk_You 16:03:26 shunan has joined #dap 16:03:47 present+ jerome_giraud 16:03:55 Present+ Cullen_Jennings 16:03:56 kaz has joined #dap 16:03:58 noriya has joined #DAP 16:04:01 marengo has joined #dap 16:04:04 Present+ Niklas_Widell 16:04:19 Present+ Marco_Marengo 16:04:33 Present+ Laszlo_Gombos 16:04:37 spoussa has joined #dap 16:04:38 Chair: Robin_Berjon, Frederick_Hirsch 16:04:54 Present+ Kangchan_Lee 16:05:00 Present+ Robin_Berjon, Frederick_Hirsch 16:05:01 karen has joined #DAP 16:05:15 Frankie has joined #dap 16:05:31 ceyrigno has joined #dap 16:05:50 [Introductions of attendees] 16:06:21 dsr has joined #dap 16:06:29 richt has joined #dap 16:06:50 Present+ Rich_Tibbett 16:06:56 Present+ Anssi_Kostiainen 16:07:02 Jongyoul_Park has joined #DAP 16:07:03 Present+ Olivier_Thereaux 16:07:12 Frederick: Please join the irc channel 16:07:14 Present+ Christophe_Eyrignoux 16:07:15 Luca has joined #dap 16:07:17 Present+ Jongyoul_Park 16:07:18 Present+ Sakari_Poussa 16:07:19 watar has joined #dap 16:07:19 Present+ Soonbo_Han 16:07:19 Dom: when you start speaking, please restate your name before speaking 16:07:20 kepeng has joined #dap 16:07:22 jcdufourd has joined #dap 16:07:28 Present+ Matt_Hammond 16:07:30 Youngsun has joined #dap 16:07:35 yosuke has joined #dap 16:07:38 adrianba has joined #dap 16:07:40 nvbalaji has joined #dap 16:07:41 Cathy has joined #dap 16:07:42 rrsagent, draft minutes 16:07:42 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html kaz 16:07:45 Present+ JC_Dufourd 16:07:47 Present+ Cathy_Chan 16:07:50 Present+ Adrian_Bateman 16:07:59 Present+ Ingmar_Kliche 16:08:12 Present+ Youngsun_Ryu 16:08:12 [teleconference bridge may be set up if someone tries to dial in] 16:08:13 Present+ Balaji_NV 16:08:27 Clarke has joined #dap 16:08:31 Present+ Dave_Raggett 16:08:32 Mani has joined #dap 16:08:40 rbardini has joined #dap 16:08:50 Present+ Clarke_Stevens 16:08:58 Present+ Kaz_Ashimura 16:09:13 [About 60 people in the room] 16:09:13 Present+ mahalingam_mani 16:09:14 helena has joined #dap 16:09:15 francois has joined #dap 16:09:18 Robin: we will begin with a short presentation on discovery 16:09:18 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011%2C_Santa_Clara_(TPAC) 16:09:20 ...then a few demos 16:09:27 rrsagent, generate minutes 16:09:27 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html fjh 16:09:28 youenn has joined #dap 16:09:30 ...so people can get a feel for how discovery works 16:09:33 BobLund has joined #dap 16:09:36 ...then look at potential solutions 16:09:39 aizu_ has joined #dap 16:09:40 ...look at Web intents 16:09:47 ...approaches we want to discuss 16:09:54 Present+ aizu 16:10:42 First presenter is Giuseppe Pascale, Opera 16:10:52 Kihong_Kwon has joined #dap 16:10:59 Title of presentation: Networked Service Discovery and Messaging 16:11:21 Giuseppe: Web and TV IG has been looking at use cases for home network discovery 16:11:24 http://people.opera.com/giuseppep/hntf 16:11:31 -> http://people.opera.com/giuseppep/hntf Networked Service Discovery and Messaging, Giuseppe Pascale 16:11:34 ...We started from simple question; looking at what all devices in home have in common 16:11:37 Present+ Art_Barstow 16:11:37 ...they all run a browser 16:11:42 ...they are connected to the home network 16:11:46 ...Look at other facts, numbers 16:11:56 ...A lot of people surf the internet while watching TV 16:12:53 karenm has joined #DAP 16:13:26 59% of Americans browse the web on different devices while they are watching TV * Nielsen Research http://blog.nielsen.com/nielsenwire/online_mobile/three-screen-report-q409/ 16:13:37 Giuseppe describes scenarios of ways people can interact with devices 16:13:51 Giuseppe: So are we there yet? Can we do this today? Answer is almost 16:13:58 ...Each of these use cases require three steps 16:14:14 ...Discovery, authorization and third step is communication 16:14:25 ...then devices start to communicate 16:14:29 ...If we look at three steps 16:14:34 ...Download is nothing to be done 16:14:48 ...But looking at Discovery, it's not something you can do today in a Web Application 16:15:11 ...What we will enable is to allow services to be aware of services and allow them to advertise themselves 16:15:14 ...Being able to support this is important 16:15:23 ...people could immediately use own devices 16:15:34 ...We did not see major gaps with communications 16:15:38 ...UPnP is based on SOAP 16:15:46 ...so don't have to invent a new messaging protocol 16:15:59 francois has joined #dap 16:15:59 ...Use cases where you just want the devices to communicate 16:16:16 ...The only real problem using this technology is constraint to same IP 16:16:23 helena has joined #dap 16:16:31 ...cannot communicate with normal Web messaging; may want to relax this restriction 16:16:33 ernesto_jimenez_ has joined #dap 16:16:34 jfmoy has joined #dap 16:16:34 richt has joined #dap 16:16:34 yosuke_ has joined #dap 16:16:36 fluffy has joined #dap 16:16:37 marengo_ has joined #dap 16:16:41 ...So these were the main conclusions our group made 16:16:53 Frankie has joined #dap 16:16:58 ...So CableLabs and Opera we looked at these use cases 16:16:59 nwidell has joined #dap 16:17:05 aizu has joined #dap 16:17:22 ...What we found is that the gaps are small 16:17:22 ...We all want application to do the get of services 16:17:22 ...Application doesn't need to know; just ask for some kind of service 16:17:23 Luca has joined #dap 16:17:24 darobin has joined #dap 16:17:30 ...Gets a pointer, a URL, and communicate using normal Web stuff 16:17:41 ...Only new thing is [this] 16:17:48 kaz_ has joined #dap 16:17:50 ...That is what led to this conclusion 16:18:00 s/[this]/navigator.getNetworkServices/ 16:18:11 ...Then we created a task force to look into these use cases; and we published a report 16:18:12 Jerry has joined #dap 16:18:15 ...There are more use cases described there; references to existing standards 16:18:27 Present+ Richard_Bardini 16:18:27 ...We would really like to discuss these use cases and decide which is the right approach 16:18:34 ...We are open to discussion 16:18:36 ...thank you 16:18:57 Zakim, room for 5 for 480 minutes 16:18:57 I don't understand 'room for 5 for 480 minutes', dom 16:19:00 Zakim, room for 5 for 480 minutes? 16:19:01 ok, dom; conference Team_(dap)16:19Z scheduled with code 26633 (CONF3) for 480 minutes until 0019Z 16:19:01 [Zakim bridge to start] 16:19:21 Team_(dap)16:19Z has now started 16:19:39 Marcos: It was not clear to me 16:19:45 jcdufourd has joined #dap 16:19:47 ...a bunch of people like to watch TV while surfing Internet 16:19:51 ...Is that the same experience? 16:19:57 ...Am I on tablet, laptop? 16:20:02 ...where is content coming from 16:20:11 ...How does Web content meet ? 16:20:17 Giuseppe: TV content is not different from web content 16:20:35 ...So far we are experiencing content on one screen; can I distribute to different screens? 16:20:45 ...Can we distribute social onto other screens? 16:20:54 adrianba has joined #dap 16:20:56 Marcus: So to render content on both devices 16:21:12 Giuseppe: have complementary content on two screens, reuse what is already available 16:22:12 s/Marcus/Marcos/ 16:22:22 helena_ has joined #dap 16:22:38 Cullen: I have a question about the security model 16:22:50 ... Most implementations of UPNP assume the local network is safe 16:22:56 jfmoy_ has joined #dap 16:22:56 Frankie has joined #dap 16:22:56 richt has joined #dap 16:22:57 ... doesn't require credentials on the local network 16:22:57 helena has joined #dap 16:22:57 Luca has joined #dap 16:22:58 lgombos has joined #dap 16:22:59 fluffy_ has joined #dap 16:22:59 Anders has joined #dap 16:23:01 gilles has joined #dap 16:23:12 ... does this model mean that any random web site can access local network resources? 16:23:21 a12u has joined #dap 16:23:23 spoussa has joined #dap 16:23:23 will has joined #dap 16:23:24 Giuseppe: in the opera prposal, this is taken care via the user agent 16:23:24 nwidell has joined #dap 16:23:26 Kihong_Kwon has joined #dap 16:23:26 Youngsun has joined #dap 16:23:32 Jongyoul_Park has joined #DAP 16:23:35 ... the UA asks whetehr you want to allow a given web app to access your local services 16:23:43 ... before that point, no communication is possible 16:23:43 ryoichi has joined #dap 16:23:47 fjh has joined #dap 16:23:48 shunan has joined #dap 16:23:55 aizu has joined #dap 16:23:55 ... But FWIW, this is already possible today via Android applications 16:23:56 gilles has left #dap 16:24:08 q? 16:24:10 cullen-jennings: what about security,e.g. UpNP makes certain assumptions 16:24:11 darobin has joined #dap 16:24:15 Marcos: the threat model is a bit different there 16:24:20 ... an adroid application doesn't have as much power as something on the open Web 16:24:24 s/whetehr/whether/ 16:24:24 abarsto has joined #dap 16:24:28 Kai has joined #dap 16:24:29 marengo_ has joined #dap 16:24:45 ceyrigno has joined #dap 16:24:47 yosuke has joined #dap 16:24:48 @@@: How about the TV? Does the TV get a chance to authorize the mobile device? 16:24:51 ernesto_jimenez has joined #dap 16:24:52 ... like some kind of peering? 16:24:57 SungOk_You has joined #dap 16:25:12 karen has joined #DAP 16:25:15 Giuseppe: the examples I showed are based on UPnP 16:25:15 ... we're reusing that infrastructure 16:25:15 jcdufourd_ has joined #dap 16:25:17 @dom, my response: There's a decision that needs to be made at connection time. The user needs to decide if they trust the web site to access this X resource. Brokered by the UA. 16:25:24 s/@@@/nvbalaji./ 16:25:28 mav has joined #dap 16:25:37 s/nvbalaji./nvbalaji/ 16:25:44 q+ sicking 16:25:46 Marcus: you don't have a choice 16:26:14 Jean-Claude: UPnP is one of the protocols that Opera is implementing as an example 16:26:19 Jean-Claude: we don't want to lock ourselves with UPnP 16:26:24 shan has joined #dap 16:26:28 ... in the various protocols, there are occasions for security / authentication 16:26:32 @@@: @@@ 16:26:32 giuseppe: as shown in the slides, this allows browser to connect your devices 16:26:32 ... using more secure way 16:26:37 [ my connection is also very unstable... ] 16:26:37 ... but that's protocol dependent 16:26:38 Giuseppe: We are enabling security with two devices 16:26:39 JC: there is a communication protocol 16:26:50 adrianba has joined #dap 16:26:55 JC: in between request for discovery and answer... 16:26:55 bryan has joined #dap 16:26:56 sicking has joined #dap 16:26:58 q? 16:27:15 GP: the application can only ask for a type and get them 16:27:15 ...there is user agent 16:27:19 ...everything is hidden; you cannot info about your home network 16:27:27 Marcus: that is ideal; that isnot being exposed 16:27:33 GP: define some type of devices 16:27:41 s/Marcus/Marcos/g 16:27:42 ...and the suer agent says yeah, you have one 16:27:52 Marcos has joined #dap 16:27:54 s/suer/user/ 16:27:55 ...this is device available at this URL 16:27:55 ...user has authorized it 16:27:56 +q 16:28:14 ...how this is shown by user agent in way user understands is a big question 16:28:17 ack sicking 16:28:38 Jonas: sounds like you are getting this to work on existing hardware 16:28:44 JC: Giuseppe's example was only an example, mention of UPnP did not imply we want to use UPnP in the end, just a discovery protocol, and for security, we are just saying that there is a step in between discovery request and response where a security policy is applied 16:28:49 ...are you looking at different security scenarios? 16:28:52 dsr has joined #dap 16:29:03 Present+ Dave_Raggett 16:29:12 GP: enabling something not tied to any protocol if you establish a channel 16:29:14 ...user agent may say not allow to communicate with any device 16:29:20 ...this is one approach 16:29:20 Present+ Josh_Soref 16:29:20 q? 16:29:26 ...if people are concerned they can say now 16:29:26 q+ to talk about use case diversity 16:29:29 s/now/no 16:29:43 Jonas: where we can enable for security models 16:29:48 noriya has joined #dap 16:29:54 GP: underlying protocol; we recommend two 16:29:56 q? 16:30:02 ...if there is third or fourth it should be transparent 16:30:11 ...new service; how to discover it; have a menu 16:30:22 ...so doesn't have to be discovred in traditional way 16:30:26 R_Berkoff has joined #dap 16:30:31 s/discovred/discovered/ 16:30:32 ? Abstraction of that process 16:30:37 ...where innovation happens 16:30:43 jongyoul has joined #dap 16:30:44 ...keep innovation; a high priority 16:30:47 s/?/richt:/ 16:30:50 AnssiK has joined #dap 16:30:51 Robin: BBC wrote a protocol... 16:30:51 draggett has joined #dap 16:31:02 -> http://people.opera.com/richt/release/specs/discovery/Overview.html Networked Service Discovery and Messaging proposal from Opera and CableLabs 16:31:15 Olivier: We looked at a lot of use cases; many have been mentioned 16:31:15 ...many users in the home 16:31:19 ...We don't necessarily want the kid's PC to control the TV 16:31:21 q? 16:31:30 ...we built a prototype that does discovery, pairing, control, reading info 16:31:35 rbardini has joined #dap 16:31:36 ...done centralized on set-top box 16:31:37 [one thing that seems to be protocol specific is the identification of the "type" of services that is to be discovered] 16:31:39 q? 16:31:40 q+ 16:31:47 ack Mar 16:31:48 ...What I hear proposed is interesting...have every device be a first class citizen 16:31:54 ack Marcos 16:32:02 Marcos: about new protocols 16:32:11 ...would be great if Web and TV could look into that 16:32:17 ...what is the common model to be used 16:32:21 JanL has joined #dap 16:32:24 ...then could be abstracted if something new is needed 16:32:28 ...to follow up 16:32:34 jgiraud has joined #dap 16:32:36 ...Like Web and TV group to answer how much 16:32:42 ...what these protocols provice 16:32:49 ...UPnP spec is huge and inaccessible 16:33:01 ...DLNA is claiming how many billions of devices 16:33:10 Clarke: ? 16:33:11 -> http://www.bbc.co.uk/rd/publications/whitepaper194.shtml the Universal Control API (BBC) 16:33:22 kepeng has joined #dap 16:33:25 Marcos: have a human accessible list to see what we can do; control volume, etc. 16:33:35 ...What would be needed if a new protocol is needed? 16:33:37 GP: Two things 16:33:37 ? 16:33:39 q? 16:33:42 ...this was completion of our group 16:33:44 RRSAgent, draft minutes 16:33:44 I have made the request to generate http://www.w3.org/2011/11/03-dap-minutes.html timeless 16:33:45 ...per the charter 16:33:52 ...This group will have to answer 16:33:53 Zakim, close queue 16:33:53 ok, darobin, the speaker queue is closed 16:34:00 Marcos: So we will have to work together to answer it 16:34:12 ...discover something, but now I cannot do anything with it 16:34:17 GP: we also discussed high vs low level 16:34:24 s/Clarke: ?/Clarke: DLNA referes UPnP./ 16:34:30 ...do you want to abstract in high level 16:34:37 Marcos: don't want to go there; too early 16:34:44 q? 16:34:46 Robin: queue is closed 16:34:53 Zakim, close the queue 16:34:53 ok, timeless, the speaker queue is closed 16:35:11 Marcos, Bryan, and Robin 16:35:20 Marcos: we have to look at the licenses around these technologies and the implications 16:35:24 Robin: I think they are pretty bad 16:35:27 Marcos: we don't know 16:35:38 If I understand one goal expressed, it would be to facilitate both existing and new devices through an API abstraction which is tied to neither. That seems like a good goal for the initial API. Is that considered a high-level or low-level API? 16:35:38 Robin: UPnP is ?; DLNA 16:35:44 s/?/RAND0/ 16:35:44 GP: spec does not mention any 16:35:52 Bryan: if I understand one goal 16:36:15 ack darobin 16:36:15 darobin, you wanted to talk about use case diversity 16:36:15 ...it would be to facilitate new devices that are tied to neither 16:36:15 ...a good goal 16:36:19 Robin: a comment on presentation and discussion 16:36:20 ack bryan 16:36:23 ...what I find notable 16:36:29 ...this is a generic discovery API 16:36:34 s/RAND0/RAND-Z 16:36:36 ...have you guys looked at... 16:36:41 s/RAND0/RAND-Z/ 16:36:49 ...other things that people like me who don't have a TV would be interested in 16:36:58 ...I could not watch two screens at once since I don't have a TV 16:37:14 [?] Good point 16:37:14 ...look at services; what is local 16:37:15 ...is this something we are going to do 16:37:20 Robin: if only controlling TVs 16:37:26 GP: if you watch content 16:37:30 ...vs not have a TV 16:37:37 ...could watch content on your PC 16:37:47 s/[?]/richt:/ 16:37:47 Robin: Why would I have it on ten devices? I have a PC 16:37:54 ...just saying it's important to look at other devices 16:38:01 ...If I can access an extend network 16:38:11 ...something about no assumption; and is it possible 16:38:13 clarke: today it is possible 16:38:15 s/extend/extended/ 16:38:20 Robin: hands around the room 16:38:26 There are many more devices of interest than TVs, cars, remote sensors, home healthcare, home security, heating and lighting, it is very open ended. 16:38:31 Bob Lund: this is not limited to multiple screens 16:38:37 ...can access multiple devices 16:38:44 ...UPnP can talk to your thermometer 16:38:53 Jan: prototype surrounding discovery 16:39:00 ...allows you to discover content, formats 16:39:16 ...see what is most compatable with your device 16:39:16 ...example of not TV based 16:39:21 ...there is other potential regarding that 16:39:24 ...in homes 16:39:44 JC: the use case we brought was multiscreen 16:39:55 ...TV was one example that spoke to most people 16:40:11 ...one important thing was to have use cases where things move around dynamically after start of various switches 16:40:24 Jonas: a non-device we would like to talk to 16:40:28 ...people's home routers 16:40:40 ...that scares me if Web pages can open up a dialogue on users browsers 16:40:44 GP: user agent... 16:41:00 Jonas: If all I need is... 16:41:15 Jean-Francois: We were talking about TV screens 16:41:19 ...seems to bother you 16:41:28 ...you can imagine listening to a podcast, go to car 16:41:33 Kangchan has joined #dap 16:41:36 ...and transfers to car; continuous journey 16:41:41 ...over different locations and devices 16:41:46 Robin: second screen 16:41:54 ...let's go to Webinos 16:41:55 Any native application on any device can already pwn your router if it wants to. 16:42:00 s/Webinos/demos/ 16:42:02 Clarke: this discovery protocol...is a single API 16:42:15 ...assumption is device discovered in some fashion, connected electronically 16:42:22 ...way you communicate is up to user agent 16:42:34 richt, true, but native apps needs to be installed in the first place; you can't fall upon them just by clicking a random obscure link 16:42:34 ...could speak an IP based protocol, USB, Bluetooth 16:42:42 ...have to write some code to do that discovery 16:42:44 ...that is only question 16:42:47 ...no assumption 16:43:00 ...turns out I work for company interested in TV; why my assumptions are based on that 16:43:12 [Clarke Stevens to demo] 16:43:20 re the point about risk of routers with UPNP interfaces being taken over by a single browser action: it's not possible in most routers to take control via a simple button from a browser on the network - most routers have some sort of admin login enforced, but I agree that it would be bad if that security was diminished in any way by this 16:43:21 noah has left #dap 16:43:29 Clarke: I have UPnP servers; mini DLNA 16:43:36 ...demonstrates two protocols 16:43:40 ...I am currently using two 16:43:45 ...bringing up a regular web page 16:43:52 ...the way I implemented it 16:44:16 ...and how Opera has done in browser code itself is user agent is a Java applet 16:44:16 ...web page is typical; HTML, CSS, Javascript 16:44:22 ...two things in applet; get network services 16:44:26 ...three parameters 16:44:29 ...type of service to find 16:44:34 ...showing UPnP service 16:44:40 ...passes URN that identified that service 16:44:42 -> http://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0400.html CableLabs Discovery API Implementation as a Java applet (Member-only archive) 16:44:52 ...other is MTDAP [?] 16:45:15 ...everything else is on the network; only discovering those types of services 16:45:15 ...also implemented in the applet 16:45:22 ...XHR that does cross 16:45:28 s/cross/cross-origin stuff/ 16:45:52 ...to security question, this authorizes browser to get the applet 16:46:00 ...I've got a Java consol here to see what is happening 16:46:11 ...now applet has started 16:46:17 ...start UPnP Discovery and it starts discovery process to find devices 16:46:26 FYI, we will make 'Start UPnP Discovery' and 'Start mDNS Discovery' as a background process in the UA...like we do with Opera Unite with zero performance interruption. 16:46:36 ...Once it's discovered, this asks to find two devices 16:46:39 ...on the network 16:46:43 ...a check box here 16:46:53 ...So far the web page knows nothing about devices; all in the user agent 16:47:00 ...If I don't check it still doesn't know 16:47:14 ...have to check and say ok 16:47:14 ...Now it knows about those devices 16:47:15 ...communication is nothing new 16:47:21 ...using XHR, Web Sockets 16:47:26 ...whatever protocol you are using 16:47:30 ...Calls are identical 16:47:43 ...Looking for adapt server, calling different code within Java applet 16:47:52 ...call it again and it recognizes that something has been discovred 16:47:56 ...showing three services here 16:48:00 ...just to show communications 16:48:16 ...let me browse down tree 16:48:16 ...generating SOAP 16:48:16 ...come back again 16:48:24 ...pop up same services it found before; uncheck one 16:48:30 ...now communication with that service is disabled 16:48:35 ...web page could store that 16:48:41 ...no communication allowed between that 16:48:43 q+ 16:48:45 ...that's it 16:48:51 [applause] 16:48:54 GP: quick comment 16:48:58 Zakim, open the queue 16:48:58 ok, timeless, the speaker queue is open 16:49:03 q+ bryan 16:49:13 ...communication part can be used with off the shelf products already 16:49:17 Robin: that's a security problem 16:49:26 GP: widget is allowed to communicate 16:49:36 Marcos: I still think that you guys are doing 16:49:40 ...approaching in a weird way 16:49:44 Robin: the architecture? 16:49:59 Dave Raggett, W3C 16:49:59 AnssiK has joined #dap 16:50:02 I wonder how the owner of the devices that are discoverable can be a part in this process. Is it assumed that any access controls are included here, except on the discovering user's case? 16:50:11 DaveR: I'm going to show you another way of discovery 16:50:14 AnssiK has joined #dap 16:50:17 ...Webinos is discovering apps across devices 16:50:24 ...BMW is one of the participants 16:50:32 Dave: this is an Android phone 16:51:01 ...top part of display shows incoming requests 16:51:15 ...advertises the IP address 16:51:15 ...running UPnP and local web server 16:51:15 ...bottom is screen preview 16:51:26 Scribe: Josh_Soref 16:51:28 ...I'll show you API is a second 16:51:31 ScribeNick: timeless 16:51:41 sejinpark has joined #dap 16:51:43 XX: it's discovered the phone 16:51:53 s/XX/DSR/ 16:52:02 ... this is where Zeroconf/XX1 take different approaches 16:52:15 ... and the naming may matter to users 16:52:20 darobin: this could be solved 16:52:25 ... elsewhere 16:52:43 dsr: hopefully the users will give better names to their devices as they see them 16:52:55 dsr: jumping backwards 16:52:56 wma has joined #dap 16:53:13 ... i developed a plugin that exposes EVERYTHING 16:53:13 ... it's a nightmare 16:53:13 [ dsr demos a thing listing everything ] 16:53:20 dsr: SSDP is commmon and Zeroconf 16:53:34 ... exposing everything makes fingerprinting trivial 16:53:44 [ dsr shows a dialog ] 16:53:55 dsr: this dialog shows what's available 16:54:01 ... and it shows who's showing the dialog 16:54:14 that brings up the essence of my note above: is it assumed that the users of all the accessible devices are responsible for the access to their devices? 16:54:15 ... i don't know that it's enough for informed consent 16:54:22 [ dsr: darobin look at the picture ] 16:54:41 dsr: you've discovered a ReSTful service for an unrestful feature 16:54:47 [ picture of darobin squirming ] 16:54:56 s/feature/picture/ 16:54:58 dsr: user's and end user's perspective are critical 16:55:12 bryan: do we assume that things out in cloud is out of scope? 16:55:16 q? 16:55:19 q+ 16:55:22 dsr: i think AC is out of scope 16:55:35 ... a lot of people out here are advertising themselves 16:55:44 ... and they might not be totally aware that they're doing that 16:55:46 ack bryan 16:55:50 ... but it's a separate issue 16:55:58 Clarke: i'll post a url on irc for our app 16:56:11 darobin: thanks all for the demos 16:56:12 ... it's nice for something concrete 16:56:23 ... i'd like to get into the arch issues that several people have been talking about 16:56:26 Mani has joined #dap 16:56:32 ... one of the things i've heard a lot of concern about 16:56:35 link to Dave's demo? 16:56:38 ... is that you can list services 16:56:39 FYI, some mockups of the UA UI for security/authorization: 16:56:40 http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_1.png 16:56:42 http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_2.png 16:56:43 ... yes it's user mediated 16:56:55 ... but is that something you want to tell an app if you can avoid it? 16:57:01 ... say you want to print something 16:57:11 ... either "list me all the printers", i "show you the list of printers" 16:57:13 does minimization apply to discovery 16:57:16 ... then you print something 16:57:22 q+ 16:57:25 ... alternatively, you could say "i want to print something" 16:57:52 helena_ has joined #dap 16:57:54 JC: avoid "user mediated" to say "mediated" 16:58:13 darobin: we have a rule that you have to drink if you say "policy" 16:58:20 darobin: is it more useful/more secure to get a list of services to the application 16:58:22 +q 16:58:36 ... or to have the app say "i want to do X to Y" and never let it know what it's talking to 16:58:52 G: there could be cases when you need to talk to it 16:59:12 darobin: so you get a Worker 16:59:12 G: some systems never want to be exposed 16:59:19 darobin: yeah, that's what i'm aiming at 16:59:27 q? 16:59:30 ack me 16:59:31 bryan: that brings up the Roles of the Users in this Equation 16:59:33 ack bryan 16:59:46 ... user has to make a decision about whether ti's good for things to see stuff 16:59:52 Clarke has joined #dap 16:59:59 ... there's also a decision about knowing if things should be seen of remote devices 17:00:13 ... there's an assumption of single owner on a home network 17:00:13 Present+ Clarke_Stevens 17:00:14 ... that falls apart in the coffee shop 17:00:24 q? 17:00:29 ... we need to think about roles of users involved in making things accessible 17:00:29 Here is the URL where you can get the CableLabs demo: http://lists.w3.org/Archives/Member/w3c-archive/2011Oct/0400.html 17:00:30 ack Marcos 17:00:45 Marcos: your example of the printer was a good one 17:00:53 ... when you go to print from a web page 17:01:00 ... you just press apple-p/cmd-p 17:01:01 q+ to mention connection to social networks as a means for describing sharing preferences 17:01:15 ... you get an intent to print 17:01:18 ... i never need to expose the api of the printer to the web page 17:01:22 ... i'm able to print 17:01:27 ... i think tha's a good model 17:01:39 ... if this functionality is explored, i'd like to see that explored 17:01:47 ... i'd like to see where it breaks down 17:01:50 We need to think about the roles of the users accessing devices (the user may want to limit their browser to access only certain devices, whether or not they own/trust the devices), and the role of the owner of those other devices. These roles are very different in the home vs a public space. 17:01:53 Clarke: I think that breaks down at the first step 17:02:13 ... because the point is to let the web page have that interface 17:02:23 ... if you have a TV or something 17:02:32 Marcos: give me a more concrete use case 17:02:46 ... say i have facebook and i want to have something on the screen 17:02:59 ... or i go to facebook, and i want to play radio somewhere 17:03:12 ... let's cover the 90% UCs 17:03:19 dsr: there are many different UCs for accessing services 17:03:34 ... the number of services, some will be defined by us, some by others 17:03:45 q+ 17:03:45 G: we were thinking about looking at Web Intents 17:04:00 darobin: I heard something interersting 17:04:01 q+ 17:04:13 ... I heard simple use cases and I heard Intents 17:04:17 ... it could be very much intereesting to see code 17:04:20 ... about how simple UCs 17:04:27 ... that Marcos was talking about 17:04:30 ... could be done with Intents 17:04:37 s/intereesting/interesting/ 17:04:47 ... this is a debate that happens for a lot of apis 17:04:52 ... do you do low level or high level 17:04:52 +1 to quick production of code examples that illustrate how discovery and intents help here. 17:05:00 ... low better for innovation, high better for security 17:05:14 ... there's no set rule 17:05:14 ... it would be useful for moving forward 17:05:15 ... to see a simple high level intents api 17:05:22 ... and a discovery api 17:05:36 Clarke: my url has 3 examples + source code 17:05:42 G: how do we move forward? 17:05:54 ... it would be useful to have the discussion in the sample place/group 17:05:55 q? 17:06:14 ack dsr 17:06:14 dsr, you wanted to mention connection to social networks as a means for describing sharing preferences 17:06:15 ack dsr 17:06:16 dsr: we spoke about AC a while back 17:06:23 ... it involved stuff in your own home 17:06:31 ... there's stuff for social networks 17:06:36 ... and what do you share with your friends 17:06:46 ... how do users think about their services and control how they're used 17:06:48 ack fjh 17:06:49 q? 17:06:57 fjh: we have different proposals about Discovery 17:07:01 ... one from Opera 17:07:11 q+ 17:07:13 ... one from Webinos 17:07:15 ... should we talk about other fundamental differences in approaches 17:07:20 karenm has joined #DAP 17:07:25 +1 to Dave's comment - intents as I understand it is about use cases outside the home - in the cloud 17:07:31 q+ 17:07:31 ... i'm not sure i understand what Arch issues are significant that we might not have been discussed 17:07:37 ... dsr mentioned Naming 17:07:43 ... another was timing for Discovery 17:07:47 (I don't think Intents are particularly limited to cloud-based services) 17:07:50 ... impact on Battery 17:08:14 ... not sure what from Webinos that we're missing/forgetting 17:08:14 ... we should identify Issues