13:38:52 RRSAgent has joined #dap 13:38:52 logging to http://www.w3.org/2013/07/24-dap-irc 13:38:54 RRSAgent, make logs world 13:38:54 Zakim has joined #dap 13:38:56 Zakim, this will be DAP 13:38:56 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 22 minutes 13:38:57 Meeting: Device APIs Working Group Teleconference 13:38:57 Date: 24 July 2013 13:40:31 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0043.html 13:40:51 fjh has changed the topic to: dap 3279; agenda http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0043.html 13:41:10 Chair: Frederick_Hirsch 13:41:17 Present+ Frederick_Hirsch 13:42:02 Regrets+ Anssi_Kostiainen 13:42:18 Regrets+ Dominique_Hazael-Massieux 13:55:32 UW_DAP()10:00AM has now started 13:55:39 +Josh_Soref 13:55:42 scribe: Josh_Soref 13:58:00 +[IPcaller] 13:58:12 zakim, [IPcaller] is me 13:58:12 +fjh; got it 13:58:18 clear 13:58:22 zakim, who is here? 13:58:22 On the phone I see Josh_Soref, fjh 13:58:23 On IRC I see RRSAgent, fjh, tobie, trackbot, richt, mounir, Josh_Soref, slightlyoff 13:58:40 s/clear// 13:59:12 zakim, who is here? 13:59:12 On the phone I see Josh_Soref, fjh 13:59:13 On IRC I see RRSAgent, fjh, tobie, trackbot, richt, mounir, Josh_Soref, slightlyoff 14:01:10 gmandyam has joined #dap 14:01:17 + +1.858.651.aaaa 14:01:26 Zakim, aaaa is gmandyam\ 14:01:26 +gmandyam\; got it 14:01:37 Zakim, aaaa is gmandyam 14:01:37 sorry, gmandyam, I do not recognize a party named 'aaaa' 14:02:22 Zakim, gmandyam\ is really gmandyam 14:02:22 sorry, Josh_Soref, I do not recognize a party named 'gmandyam\' 14:02:23 Frederick, Am at work and they are testing the fire alarm. I am going to stay muted for right now. -Giri 14:02:40 s/Frederick, Am at work and they are testing the fire alarm. I am going to stay muted for right now. -Giri// 14:05:09 Cathy has joined #dap 14:06:16 Zakim, who is here? 14:06:16 On the phone I see Josh_Soref, fjh, gmandyam 14:06:17 On IRC I see Cathy, gmandyam, Zakim, RRSAgent, fjh, tobie, trackbot, richt, mounir, Josh_Soref, slightlyoff 14:06:18 +[IPcaller] 14:06:36 zakim, [IPcaller] is richt 14:06:36 +richt; got it 14:07:01 + +1.781.362.aabb 14:07:06 zakim, aabb is me 14:07:06 +Cathy; got it 14:08:13 RRSAgent, draft minutes 14:08:13 I have made the request to generate http://www.w3.org/2013/07/24-dap-minutes.html Josh_Soref 14:08:34 RRSAgent, make logs public 14:08:36 RRSAgent, draft minutes 14:08:36 I have made the request to generate http://www.w3.org/2013/07/24-dap-minutes.html Josh_Soref 14:08:40 Topic: Welcome, agenda review, scribe selection, announcements 14:08:40 2nd CR of Vibration API published, http://www.w3.org/TR/2013/CR-vibration-20130723/ 14:08:45 31 July teleconference cancelled 14:08:53 Topic: Minutes approval 14:09:01 Approve minutes from 10 July 2013 14:09:01 http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/att-0018/minutes-2013-07-10.html 14:09:04 RESOLUTION: Minutes from 10 July 2013 are approved 14:09:13 topic: Network Discovery 14:09:24 Editors draft updated to use Promises, http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0036.html 14:09:33 ISSUE-129 : Simplify Network Service Discovery API ;http://www.w3.org/2009/dap/track/issues/129 14:09:33 Notes added to ISSUE-129 Simplify Network Service Discovery API. 14:10:06 fjh: does promises solve this problem? 14:10:21 Zakim, mute me 14:10:21 Josh_Soref should now be muted 14:10:26 ISSUE-29? 14:10:26 ISSUE-29 -- Should DAP APIs support "API Keys" -- closed 14:10:26 http://www.w3.org/2009/dap/track/issues/29 14:10:33 Cathy: i have some comments on jcd's proposal 14:10:33 ISSUE-129? 14:10:33 ISSUE-129 -- Simplify Network Service Discovery API -- open 14:10:33 http://www.w3.org/2009/dap/track/issues/129 14:10:43 ... apparently he thinks that's not a problem 14:10:53 ... i don't think we've agreed on whether the approach is an improvement ornot 14:10:55 s/ornot/or not/ 14:11:01 richt: i looked at the issue 14:11:12 ... i don't think it's getNetworkServices() 14:11:20 ... when new services become available 14:11:27 ... getNetworkServices() could return 0 things 14:11:43 ... he's saying you have to do getNetworkServices() and then onServicesAvailable 14:11:48 ... he's asking if that's unnecessary 14:11:53 ... i think that comes down to implementation 14:12:07 ... i think jcd's viewpoint is that you don't need to wait 14:12:19 ... you don't need to get an empty object and wait for the services 14:12:26 ... i think that's oversimplifying the system 14:12:32 ... you could have 0 or more initially 14:12:35 ... things can come and go 14:12:41 ... the api is designed to handle that UC 14:12:51 ... we've removed complexity where we could 14:12:59 ... we've given flexibility to return 0 or 10 up front 14:13:02 q+ 14:13:04 ... it's slightly different from promises 14:13:15 ... i think it's unavoidable to get an object and listen to stuff 14:13:23 ... we do that off the return from getNetworkServices() 14:13:31 ... listening for the network is behind the user opt in 14:13:36 ... i think it's correct 14:13:38 ... it's flexible 14:13:48 ... i don't think the work of developers is much larger because of that 14:14:00 fjh: might be useful if you respond to the thread on the list 14:14:00 ack gmandyam 14:14:13 gmandyam: richt, it seems onServiceAvailable 14:14:18 richt_ has joined #dap 14:14:20 ... will be invoked multiple times, possibly 14:14:26 ... if the empty object is returned 14:14:30 ... my understanding of Promises 14:14:41 ... is that you really can't apply Promises to a handler 14:14:47 ... that's more than a one-time event handler 14:15:09 ... if this is an issue w/ Network Service Discovery 14:15:17 ... how easy is it tto transition? 14:15:29 richt: getNetworkServices() is designed to be called once 14:15:40 ... on that, you listen to events for services joining/leaving the network 14:15:52 ... events fire against the return object of the success callback 14:16:14 ... to adjust the services you want, you all getNetworkServices() again to get new events for it 14:16:33 gmandyam: so, in transitioning to Promises, you aren't getting rid of the event handlers 14:16:46 richt: the event handlers still exist, they're on the Promise based success object 14:17:31 fjh: XXX 14:17:37 richt: YYY 14:17:41 Cathy: one of the issues 14:17:50 ... when a web app receives a returned object that is empty 14:17:57 ... it could mean different things 14:18:02 fjh: summary - initial return happens once, not always 0 can be 1 or more, then after this initialization, you can get multiple events as services become available or unavailable 14:18:12 ... if the UA returns an empty object, it could be because there are no objects around 14:18:15 s/XXX/thus we should keep the current design and close this issue 14:18:19 s/YYY/right/ 14:18:29 ... but another UA could return an empty object because it hasn't started listening to the network 14:18:54 ... this is about how much we want to control how the UA monitors the network 14:19:11 richt: we could clarify, but we don't want to force how the UA listens to the network 14:19:17 ... it's out of scope 14:19:32 ... it creates some confusion, but you can interpret it however you want, and it will work 14:19:48 ... from a developer point of view, it doesn't change anything 14:19:57 ... you have the same code to handle services 14:20:29 Topic: Network Service Discovery - Promises 14:20:39 fjh: we had agreement from people on the list supporting it 14:20:47 ... once we've resolved these issues, we'd want to publish 14:20:58 ... i don't think we want to go around in circles 14:21:02 ... i know the MC TF did 14:21:07 richt: it was fairly straightforward 14:21:22 ... a few changes to the WebIDL, and a few changes to the services algorithm 14:21:30 ... it was a bit figuring out how to plug into Promises 14:21:44 ... it was an obvious decision 14:21:50 ... it's a good time to do it 14:22:01 ... if someone wants to make this API in the future, they'd want Promises 14:22:05 ... so it's best for us to do it 14:22:18 ... it removes the inline-callbacks from the getNetworkServices API 14:22:24 ... Promises does allow backwards compat 14:22:34 ... In Opera 12 14:22:52 ... If people add parameters to the call, we can treat them as callbacks 14:23:01 ... I like the backwards compat, it doesn't break what's out there 14:23:09 ... and what's out there is experimental anyway 14:23:21 ... everyone's looking at Promises, it's the way to handle Async calls 14:23:24 ... it needed to be done 14:23:44 fjh: we should get review from slightlyoff or someone from Promises 14:23:56 richt: that sounds good 14:24:01 Josh_Soref: thanks 14:24:25 fjh: i'll ask TAG 14:24:33 action: fjh to ask TAG for feedback on promises with Network Discovery 14:24:33 Created ACTION-644 - Ask TAG for feedback on promises with Network Discovery [on Frederick Hirsch - due 2013-07-31]. 14:24:53 ISSUE-130? 14:24:53 ISSUE-130 -- Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code -- open 14:24:53 http://www.w3.org/2009/dap/track/issues/130 14:25:12 i/130?/Topic: Network Service Discovery - Issues/ 14:25:25 fjh: this is the layering issue 14:25:31 ... richt and Cathy responded to this 14:25:38 richt: i sent an email to the list 14:25:44 ... i don't have much more to add 14:25:52 ... i see some issues with what's being requested 14:26:03 ... it's intended as a convenience, but i think it creates confusion 14:26:19 ... it could be simpler if a network service specified a fragment of an identifier 14:26:30 ... but then you have no real idea about what you're getting back 14:26:49 ... when you get something back,you'd have to check the service type 14:27:02 ... my point is that if you're doing this, you should just request the service types up front 14:27:11 ... the api lets you specify one or MORE up front 14:27:27 ... requesting something with a fragment that may or may not match that list is really not useful 14:27:37 ... you need to communicate with returned services 14:27:50 fjh: jcd is saying he wants to do things dynamically 14:27:59 Josh_Soref: personally, i agree w/ richt 14:28:12 fjh: it's hard to do w/o everyone on the call at once 14:28:33 Cathy: it brings up additional issues 14:28:44 ... even if you know you're looking for a service type 14:28:52 ... a vendor could make something different 14:29:00 ... it might be useful looking for a upnp-print service 14:29:08 q+ 14:29:11 ... but if you're also looking for hp print service and canon 14:29:20 ... but hp print service might not be what you can handle 14:29:24 ack gmandyam 14:29:32 ack gmandyman 14:29:55 gmandyam: the spec makes UPnP / mDNS discovery work 14:30:06 ... does an IANA registry that's extensible make more sense? 14:30:16 richt: do you mean section-7? 14:30:33 https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#service-discovery 14:30:39 gmandyam: if you want to do additional protocols outside UPnP/Bonjour 14:30:47 ... my understanding of IANA registries 14:30:56 ... is that you define a couple types in the W3 spec 14:31:06 ... and you point people to the IANA registry for vendor specific prefixes 14:31:22 richt: i think the api is quite simple, it's a bootstrap mechanism for services 14:31:31 ... how they're discovered is to guide the implementers 14:31:39 ... but it's designed w/ extensibility in mind 14:31:48 ... at a basic level, you specify a string type 14:31:57 ... and we have a mapping for mDNS/UPnP 14:32:04 ... the UA itself goes off and does something 14:32:10 ... and then you have objects representing stuff 14:32:18 ... then we use XHR from the web platform 14:32:35 gmandyam: but how does the extensibility take place in the spec 14:32:48 ... if your intention is to add additional text that's informative 14:33:13 richt: i'm interested in hearing about other discovery mechanisms 14:33:26 ... when i did my research, these two were a significant portion 14:33:33 ... if there's other stuff that's applicable here, 14:33:35 what is the approach for extensibility for new mechanisms 14:33:39 ... if necessary, we could add it in 14:33:51 ... for proprietary extensibility 14:33:55 ... it relies on the UA 14:34:03 ... i don't see how that would work unless the UA understands 14:34:14 ... if there's anything to talk about, we should bring it up on the list 14:34:27 gmandyam: i'll work internally on what our guys are working on 14:34:37 ... we have "AllJoin", a local discovery mechanism 14:35:15 gmandyam, are you able to make a concrete proposal related to extensibility and IANA registration? 14:35:20 ... it doesn't seem to make sense for the spec to have to be modified each time there's a new protocol 14:35:34 richt: i think it's a good point, that we should have some extensibility 14:35:44 ... i'm trying to manage complexity 14:35:49 ... we have experimental 14:36:00 ... but we don't even have stage 1 - UPnP/Bonjour 14:36:13 ... there's a tradeoff between having extensibility and knowing what it does to the UA 14:36:19 ... and having implementation experience 14:36:42 ... there's a case to be made to implement something and get something rolling before we tackle something more complexity on top 14:36:51 fjh: i'm wondering if what gmandyam is suggesting 14:36:57 ... is a way forward 14:37:17 gmandyam: you're right, i need to put a proposal together 14:37:24 richt: yes, thank you gmandyam 14:38:16 ISSUE-131? 14:38:16 ISSUE-131 -- Support UPnP device discovery by Device Type? -- open 14:38:16 http://www.w3.org/2009/dap/track/issues/131 14:39:12 Cathy: a device type can encapsulate multiple services 14:39:23 ... the device type would be the thing that an application would look for 14:39:27 detailed summary from Cathy - http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0041.html 14:39:43 ... i was trying to put together the types of changes before my leave 14:40:19 richt: i should reply on the list 14:40:22 ... i said what i needed on the list 14:40:36 ... i think this comes down to a case of grouping services by device 14:40:44 ... and it doesn't need to be combined w/ searching by device 14:40:49 ... i know what to communicate 14:40:55 ... i know how to speak "render control language" 14:41:12 ... i know how to speak "dv foo" 14:41:20 ... but i don't know how to speak "connection manager language" 14:41:35 ... the compromise is to let services say that they come from the same device 14:41:55 ... imagine you ask for RenderControl and AVTransport 14:42:01 s/dv foo/AV Transport language 14:42:10 ... and the user is asked to authorize something 14:42:21 ... and the user sees the devices instead of their features 14:42:24 ... i click "TV" 14:42:33 ... that exposes the RenderControl and AVTransport 14:42:48 ... i didn't select based on the returned services, i select based on the provider 14:43:17 ... in the callback, i get the things i asked for (RenderControl and AVTransport) without getting defunct things that i can't understand (ConnectionManager) 14:43:41 Cathy: if you search for device-types, you reduce the number of messages that go on the network 14:44:08 richt: i'm not too worried about network traffic as an optimization 14:44:42 fjh: thanks richt 14:44:53 ISSUE-132? 14:44:53 ISSUE-132 -- Announce a webapp as a Network Services Discovery -- open 14:44:53 http://www.w3.org/2009/dap/track/issues/132 14:46:01 fjh: richt, i think you were saying it's too complicated 14:46:03 s/thanks richt/thanks rich, the distinction you make is useful/ 14:46:12 richt: we've done experiments 14:46:16 ... it is complicated 14:46:25 ... if you do UPnP, you have to write a service description XML document 14:46:31 ... you have to fully describe the service 14:46:35 ... that's a lot of effort 14:46:57 ... Say i'm a web page, and i'm offline 14:47:09 ... I have audio, and i want to play the game with others on the local network 14:47:18 ... advertising myself on the local network 14:47:23 ... it isn't a crazy UC 14:47:28 ... it's something that would be cool to do 14:47:32 is this a v2 topic? 14:47:37 ... but i don't think i have the bandwidth to do it 14:47:43 ... i'd like to see proposals 14:47:47 ... there's prior art in this area 14:47:52 ... there's stuff from WebInos 14:48:54 Cathy: i agree this is a v2 or v.next topic 14:49:04 ... a lot of complexity 14:49:10 ... it could be done in parallel 14:49:12 this could be an in depended specification, work on it independently, or v.next, no need to integrate into current specification 14:50:02 proposed RESOLUTION: address ISSUE-132 , announcing web app as network service discovery as separate spec from Network Service Discovery 14:50:11 Josh_Soref: +1 14:50:19 +1 14:50:33 RESOLUTION: address ISSUE-132 , announcing web app as network service discovery as separate spec from Network Service Discovery 14:51:34 Cathy: i had comments, should i make issues? 14:51:36 fjh: yes please 14:51:42 richt: one other thing 14:51:51 ... the network service discovery is quite tied to user opt in 14:52:05 ... there's an opportunity to see if this could integrate with CORS 14:52:15 we should get PING review at some point as well, Privacy Interest group 14:52:18 ... that'd need to be initiated by the device side 14:52:27 ... that could allow less user opt in 14:52:36 ... it would need a lot of changes at the UPnP side 14:52:42 ... that would eliminate the need to opt in 14:52:50 Josh_Soref: i'm -1 on that sort of 14:53:04 ... i don't want a game to automatically play sound on some other device on my network 14:53:26 richt: it doesn't have to be CORS, but some way for a UPnP service 14:53:39 ... to say "i'm available to be contacted", so the user doesn't necessarily have to opt into sharing 14:53:50 ... the barrier to implementation is a big one 14:54:02 ... it requires a distinction in Browser Chrome 14:54:11 ... you want to make the web better w/o hurting UX 14:54:33 fjh: isn't that a different layer in the stack? 14:54:46 ... right now, i use bonjour, select a printer 14:54:57 ... with UPnP, i find a device, i don't need permissions 14:54:59 Zakim, unmute me 14:54:59 Josh_Soref should no longer be muted 14:55:30 are we talking about different protocol layers- e.g. network layer versus application layer 14:55:56 josh_soref: need to be careful here, don't want to blast music on device etc 14:56:08 … just because discoverable does not mean appropriate 14:56:35 fjh: currently if I print, bonjour just finds the printers then I select to print. permission through use? 14:56:35 richt: it's an interesting area to look at 14:56:41 ... there may be compromises to look at 14:56:49 ... there are devices advertising publicly 14:57:01 ... if we could understand the issues in doing that 14:57:23 ... it wouldn't be free for all, there needs to be some mechanism to sort them out 14:57:30 fjh: certainly need to look at privacy 14:59:12 Josh_Soref: these things don't scale well between `home` and `office` 14:59:35 ... just because a tv wants to advertise itself in the home doesn't mean it will work correctly when someone buys that cheap tv and installs it in an office 14:59:43 richt: it's a blue-sky idea 14:59:51 ... the implications are big, and useful 15:00:01 fjh: Josh_Soref, you'll send a message? 15:00:07 fjh: we'll want to do a PSIG review 15:00:17 Have to go. Thanks. -Giri 15:00:19 ... i could ask them to look at the spec, but they won't understand the technology 15:00:24 -gmandyam 15:00:28 ... i think it's premature to do that now 15:00:40 ... i'm waiting to see when the spec is ready 15:00:50 richt: we didn't have too many problems in Opera 12 Labs 15:00:56 ... we didn't do ZeroConf, only UPnP 15:01:01 ... we tweaked this a bit 15:01:09 ... we have some implementation experience 15:01:21 fjh: so i should share it with them, and let them know it's under development 15:01:26 richt: that works for me 15:01:38 fjh: should we publish first or take feedback? 15:01:53 ... they might want someone to walk them PSIG through it on a call 15:02:22 s/PSIG/PING 15:02:23 s/PSIG/PING 15:02:44 fjh: the issues that tend to come up tend to be fairly generic 15:02:49 ... you might get some feedback 15:02:54 RRSAgent, draft minutes 15:02:54 I have made the request to generate http://www.w3.org/2013/07/24-dap-minutes.html Josh_Soref 15:02:56 action: fjh to share Network Service Discovery editors draft with PING 15:02:56 Created ACTION-645 - Share Network Service Discovery editors draft with PING [on Frederick Hirsch - due 2013-07-31]. 15:03:17 Topic: Action Items 15:03:18 topic: Action Items 15:03:24 close ACTION-639 15:03:24 Closed ACTION-639 Send Vibration CR CfC and make transition request once LC disposition complete. 15:03:38 close ACTION-640 15:03:38 Closed ACTION-640 Respond to Nick and Rigo re privacy concerns in Proximity, Light. 15:04:02 fjh: i'd like to get feedback on Promises 15:04:07 ... and then i'll start thinking about publication 15:04:33 topic: Other Business 15:04:45 fjh: glad richt could make it 15:05:11 topic: Adjourn 15:05:23 trackbot, end meeting 15:05:23 Zakim, list attendees 15:05:23 As of this point the attendees have been Josh_Soref, fjh, +1.858.651.aaaa, gmandyam\, richt, +1.781.362.aabb, Cathy 15:05:25 -richt 15:05:27 -fjh 15:05:27 -Cathy 15:05:29 UW_DAP()10:00AM has ended 15:05:29 Attendees were Josh_Soref, fjh, +1.858.651.aaaa, gmandyam\, richt, +1.781.362.aabb, Cathy 15:05:31 RRSAgent, please draft minutes 15:05:31 I have made the request to generate http://www.w3.org/2013/07/24-dap-minutes.html trackbot 15:05:32 RRSAgent, bye 15:05:32 I see 2 open action items saved in http://www.w3.org/2013/07/24-dap-actions.rdf : 15:05:32 ACTION: fjh to ask TAG for feedback on promises with Network Discovery [1] 15:05:32 recorded in http://www.w3.org/2013/07/24-dap-irc#T14-24-33 15:05:32 ACTION: fjh to share Network Service Discovery editors draft with PING [2] 15:05:32 recorded in http://www.w3.org/2013/07/24-dap-irc#T15-02-56