See also: IRC log
<trackbot> Date: 24 July 2013
<scribe> scribe: Josh_Soref
<fjh> 2nd CR of Vibration API published, http://www.w3.org/TR/2013/CR-vibration-20130723/
<fjh> 31 July teleconference cancelled
<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
RESOLUTION: Minutes from 10 July 2013 are approved
<fjh> Editors draft updated to use Promises, http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0036.html
<fjh> ISSUE-129 : Simplify Network Service Discovery API ;http://www.w3.org/2009/dap/track/issues/129
<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
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
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]
<trackbot> Created ACTION-644 - Ask TAG for feedback on promises with Network Discovery [on Frederick Hirsch - due 2013-07-31].
<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
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
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
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
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
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]
<trackbot> Created ACTION-645 - Share Network Service Discovery editors draft with PING [on Frederick Hirsch - due 2013-07-31].
<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
trackbot, end meeting