# Device APIs Working Group Teleconference

## 24 Jul 2013

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Girl_Mandyam, Cathy_Chan, Rich_Tibbett, Josh_Soref

Regrets

    Anssi_Kostiainen, Dominique_Hazael-Massieux

Chair

    Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Welcome, agenda review, scribe selection, announcements][6]

    2. [Minutes approval][7]

    3. [Network Discovery][8]

    4. [Network Service Discovery - Promises][9]

    5. [Network Service Discovery - Issues][10]

    6. [Action Items][11]

    7. [Other Business][12]

    8. [Adjourn][13]

  * [Summary of Action Items][14]

* * *

<trackbot> Date: 24 July 2013

<scribe> scribe: Josh_Soref

### Welcome, agenda review, scribe selection, announcements

<fjh> 2nd CR of Vibration API published, [http://www.w3.org/TR/2013/CR-
vibration-20130723/][15]

<fjh> 31 July teleconference cancelled

### Minutes approval

<fjh> Approve minutes from 10 July 2013

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/att-0018/minutes-2013-07-10.html][16]

**RESOLUTION: Minutes from 10 July 2013 are approved**

### Network Discovery

<fjh> Editors draft updated to use Promises,
[http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0036.html][17]

<fjh> ISSUE-129 : Simplify Network Service Discovery API
;[http://www.w3.org/2009/dap/track/issues/129][18]

<trackbot> Notes added to ISSUE-129 Simplify Network Service Discovery API.

fjh: does promises solve this problem?

Cathy: i have some comments on jcd's proposal

<fjh> ISSUE-129?

<trackbot> ISSUE-129 -- Simplify Network Service Discovery API -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/129][18]

Cathy: apparently he thinks that's not a problem

... i don't think we've agreed on whether the approach is an improvement or
not

richt: i looked at the issue

... i don't think it's getNetworkServices()

... when new services become available

... getNetworkServices() could return 0 things

... he's saying you have to do getNetworkServices() and then
onServicesAvailable

... he's asking if that's unnecessary

... i think that comes down to implementation

... i think jcd's viewpoint is that you don't need to wait

... you don't need to get an empty object and wait for the services

... i think that's oversimplifying the system

... you could have 0 or more initially

... things can come and go

... the api is designed to handle that UC

... we've removed complexity where we could

... we've given flexibility to return 0 or 10 up front

... it's slightly different from promises

... i think it's unavoidable to get an object and listen to stuff

... we do that off the return from getNetworkServices()

... listening for the network is behind the user opt in

... i think it's correct

... it's flexible

... i don't think the work of developers is much larger because of that

fjh: might be useful if you respond to the thread on the list

gmandyam: richt, it seems onServiceAvailable

... will be invoked multiple times, possibly

... if the empty object is returned

... my understanding of Promises

... is that you really can't apply Promises to a handler

... that's more than a one-time event handler

... if this is an issue w/ Network Service Discovery

... how easy is it tto transition?

richt: getNetworkServices() is designed to be called once

... on that, you listen to events for services joining/leaving the network

... events fire against the return object of the success callback

... to adjust the services you want, you all getNetworkServices() again to get
new events for it

gmandyam: so, in transitioning to Promises, you aren't getting rid of the
event handlers

richt: the event handlers still exist, they're on the Promise based success
object

fjh: thus we should keep the current design and close this issue

richt: right

Cathy: one of the issues

... when a web app receives a returned object that is empty

... it could mean different things

<fjh> 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

Cathy: if the UA returns an empty object, it could be because there are no
objects around

... but another UA could return an empty object because it hasn't started
listening to the network

... this is about how much we want to control how the UA monitors the network

richt: we could clarify, but we don't want to force how the UA listens to the
network

... it's out of scope

... it creates some confusion, but you can interpret it however you want, and
it will work

... from a developer point of view, it doesn't change anything

... you have the same code to handle services

### Network Service Discovery - Promises

fjh: we had agreement from people on the list supporting it

... once we've resolved these issues, we'd want to publish

... i don't think we want to go around in circles

... i know the MC TF did

richt: it was fairly straightforward

... a few changes to the WebIDL, and a few changes to the services algorithm

... it was a bit figuring out how to plug into Promises

... it was an obvious decision

... it's a good time to do it

... if someone wants to make this API in the future, they'd want Promises

... so it's best for us to do it

... it removes the inline-callbacks from the getNetworkServices API

... Promises does allow backwards compat

... In Opera 12

... If people add parameters to the call, we can treat them as callbacks

... I like the backwards compat, it doesn't break what's out there

... and what's out there is experimental anyway

... everyone's looking at Promises, it's the way to handle Async calls

... it needed to be done

fjh: we should get review from slightlyoff or someone from Promises

richt: that sounds good

Josh_Soref: thanks

fjh: i'll ask TAG

<fjh> **ACTION:** fjh to ask TAG for feedback on promises with Network
Discovery [recorded in [http://www.w3.org/2013/07/24-dap-
minutes.html#action01][19]]

<trackbot> Created ACTION-644 - Ask TAG for feedback on promises with Network
Discovery [on Frederick Hirsch - due 2013-07-31].

### Network Service Discovery - Issues

<fjh> ISSUE-130?

<trackbot> ISSUE-130 -- Enable variety of protocols (e.g. UPnP, Bonour) with
protocol independent developer code -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/130][20]

fjh: this is the layering issue

... richt and Cathy responded to this

richt: i sent an email to the list

... i don't have much more to add

... i see some issues with what's being requested

... it's intended as a convenience, but i think it creates confusion

... it could be simpler if a network service specified a fragment of an
identifier

... but then you have no real idea about what you're getting back

... when you get something back,you'd have to check the service type

... my point is that if you're doing this, you should just request the service
types up front

... the api lets you specify one or MORE up front

... requesting something with a fragment that may or may not match that list
is really not useful

... you need to communicate with returned services

fjh: jcd is saying he wants to do things dynamically

Josh_Soref: personally, i agree w/ richt

fjh: it's hard to do w/o everyone on the call at once

Cathy: it brings up additional issues

... even if you know you're looking for a service type

... a vendor could make something different

... it might be useful looking for a upnp-print service

... but if you're also looking for hp print service and canon

... but hp print service might not be what you can handle

gmandyam: the spec makes UPnP / mDNS discovery work

... does an IANA registry that's extensible make more sense?

richt: do you mean section-7?

<fjh> [https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
#service-discovery][21]

gmandyam: if you want to do additional protocols outside UPnP/Bonjour

... my understanding of IANA registries

... is that you define a couple types in the W3 spec

... and you point people to the IANA registry for vendor specific prefixes

richt: i think the api is quite simple, it's a bootstrap mechanism for
services

... how they're discovered is to guide the implementers

... but it's designed w/ extensibility in mind

... at a basic level, you specify a string type

... and we have a mapping for mDNS/UPnP

... the UA itself goes off and does something

... and then you have objects representing stuff

... then we use XHR from the web platform

gmandyam: but how does the extensibility take place in the spec

... if your intention is to add additional text that's informative

richt: i'm interested in hearing about other discovery mechanisms

... when i did my research, these two were a significant portion

... if there's other stuff that's applicable here,

<fjh> what is the approach for extensibility for new mechanisms

richt: if necessary, we could add it in

... for proprietary extensibility

... it relies on the UA

... i don't see how that would work unless the UA understands

... if there's anything to talk about, we should bring it up on the list

gmandyam: i'll work internally on what our guys are working on

... we have "AllJoin", a local discovery mechanism

<fjh> gmandyam, are you able to make a concrete proposal related to
extensibility and IANA registration?

gmandyam: it doesn't seem to make sense for the spec to have to be modified
each time there's a new protocol

richt: i think it's a good point, that we should have some extensibility

... i'm trying to manage complexity

... we have experimental

... but we don't even have stage 1 - UPnP/Bonjour

... there's a tradeoff between having extensibility and knowing what it does
to the UA

... and having implementation experience

... there's a case to be made to implement something and get something rolling
before we tackle something more complexity on top

fjh: i'm wondering if what gmandyam is suggesting

... is a way forward

gmandyam: you're right, i need to put a proposal together

richt: yes, thank you gmandyam

<fjh> ISSUE-131?

<trackbot> ISSUE-131 -- Support UPnP device discovery by Device Type? -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/131][22]

Cathy: a device type can encapsulate multiple services

... the device type would be the thing that an application would look for

<fjh> detailed summary from Cathy - [http://lists.w3.org/Archives/Public
/public-device-apis/2013Jul/0041.html][23]

Cathy: i was trying to put together the types of changes before my leave

richt: i should reply on the list

... i said what i needed on the list

... i think this comes down to a case of grouping services by device

... and it doesn't need to be combined w/ searching by device

... i know what to communicate

... i know how to speak "render control language"

... i know how to speak "AV Transport language"

... but i don't know how to speak "connection manager language"

... the compromise is to let services say that they come from the same device

... imagine you ask for RenderControl and AVTransport

... and the user is asked to authorize something

... and the user sees the devices instead of their features

... i click "TV"

... that exposes the RenderControl and AVTransport

... i didn't select based on the returned services, i select based on the
provider

... in the callback, i get the things i asked for (RenderControl and
AVTransport) without getting defunct things that i can't understand
(ConnectionManager)

Cathy: if you search for device-types, you reduce the number of messages that
go on the network

richt: i'm not too worried about network traffic as an optimization

fjh: thanks rich, the distinction you make is useful

<fjh> ISSUE-132?

<trackbot> ISSUE-132 -- Announce a webapp as a Network Services Discovery --
open

<trackbot> [http://www.w3.org/2009/dap/track/issues/132][24]

fjh: richt, i think you were saying it's too complicated

richt: we've done experiments

... it is complicated

... if you do UPnP, you have to write a service description XML document

... you have to fully describe the service

... that's a lot of effort

... Say i'm a web page, and i'm offline

... I have audio, and i want to play the game with others on the local network

... advertising myself on the local network

... it isn't a crazy UC

... it's something that would be cool to do

<fjh> is this a v2 topic?

richt: but i don't think i have the bandwidth to do it

... i'd like to see proposals

... there's prior art in this area

... there's stuff from WebInos

Cathy: i agree this is a v2 or v.next topic

... a lot of complexity

... it could be done in parallel

<fjh> this could be an in depended specification, work on it independently, or
v.next, no need to integrate into current specification

<fjh> proposed RESOLUTION: address ISSUE-132 , announcing web app as network
service discovery as separate spec from Network Service Discovery

Josh_Soref: +1

<Cathy> +1

**RESOLUTION: address ISSUE-132 , announcing web app as network service
discovery as separate spec from Network Service Discovery**

Cathy: i had comments, should i make issues?

fjh: yes please

richt: one other thing

... the network service discovery is quite tied to user opt in

... there's an opportunity to see if this could integrate with CORS

<fjh> we should get PING review at some point as well, Privacy Interest group

richt: that'd need to be initiated by the device side

... that could allow less user opt in

... it would need a lot of changes at the UPnP side

... that would eliminate the need to opt in

Josh_Soref: i'm -1 on that sort of

... i don't want a game to automatically play sound on some other device on my
network

richt: it doesn't have to be CORS, but some way for a UPnP service

... to say "i'm available to be contacted", so the user doesn't necessarily
have to opt into sharing

... the barrier to implementation is a big one

... it requires a distinction in Browser Chrome

... you want to make the web better w/o hurting UX

fjh: isn't that a different layer in the stack?

... right now, i use bonjour, select a printer

... with UPnP, i find a device, i don't need permissions

<fjh> are we talking about different protocol layers- e.g. network layer
versus application layer

<fjh> josh_soref: need to be careful here, don't want to blast music on device
etc

<fjh> josh_soref: just because discoverable does not mean appropriate

<fjh> fjh: currently if I print, bonjour just finds the printers then I select
to print. permission through use?

richt: it's an interesting area to look at

... there may be compromises to look at

... there are devices advertising publicly

... if we could understand the issues in doing that

... it wouldn't be free for all, there needs to be some mechanism to sort them
out

fjh: certainly need to look at privacy

Josh_Soref: these things don't scale well between `home` and `office`

... 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

richt: it's a blue-sky idea

... the implications are big, and useful

fjh: Josh_Soref, you'll send a message?

... we'll want to do a PING review

<gmandyam> Have to go. Thanks. -Giri

fjh: i could ask them to look at the spec, but they won't understand the
technology

... i think it's premature to do that now

... i'm waiting to see when the spec is ready

richt: we didn't have too many problems in Opera 12 Labs

... we didn't do ZeroConf, only UPnP

... we tweaked this a bit

... we have some implementation experience

fjh: so i should share it with them, and let them know it's under development

richt: that works for me

fjh: should we publish first or take feedback?

... they might want someone to walk them PING through it on a call

... the issues that tend to come up tend to be fairly generic

... you might get some feedback

<fjh> **ACTION:** fjh to share Network Service Discovery editors draft with
PING [recorded in [http://www.w3.org/2013/07/24-dap-
minutes.html#action02][25]]

<trackbot> Created ACTION-645 - Share Network Service Discovery editors draft
with PING [on Frederick Hirsch - due 2013-07-31].

### Action Items

<fjh> close ACTION-639

<trackbot> Closed ACTION-639 Send Vibration CR CfC and make transition request
once LC disposition complete.

<fjh> close ACTION-640

<trackbot> Closed ACTION-640 Respond to Nick and Rigo re privacy concerns in
Proximity, Light.

fjh: i'd like to get feedback on Promises

... and then i'll start thinking about publication

### Other Business

### Adjourn

trackbot, end meeting

## Summary of Action Items

**[NEW]** **ACTION:** fjh to ask TAG for feedback on promises with Network
Discovery [recorded in [http://www.w3.org/2013/07/24-dap-
minutes.html#action01][19]]

**[NEW]** **ACTION:** fjh to share Network Service Discovery editors draft
with PING [recorded in [http://www.w3.org/2013/07/24-dap-
minutes.html#action02][25]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][26] version 1.135 ([CVS
log][27])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/0043.html

   [4]: http://www.w3.org/2013/07/24-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #ActionSummary

   [15]: http://www.w3.org/TR/2013/CR-vibration-20130723/

   [16]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/att-0018/minutes-2013-07-10.html

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/0036.html

   [18]: http://www.w3.org/2009/dap/track/issues/129

   [19]: http://www.w3.org/2013/07/24-dap-minutes.html#action01

   [20]: http://www.w3.org/2009/dap/track/issues/130

   [21]: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
#service-discovery

   [22]: http://www.w3.org/2009/dap/track/issues/131

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2013Jul/0041.html

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

   [25]: http://www.w3.org/2013/07/24-dap-minutes.html#action02

   [26]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [27]: http://dev.w3.org/cvsweb/2002/scribe/