See also: IRC log
<trackbot> Date: 24 July 2013
<scribe> scribe: Josh_Soref
<gmandyam> Frederick, Am at work and they are testing the fire alarm. I am going to stay muted for right now. -Giri
s/Frederick, Am at work and they are testing the fire alarm. I am going to stay muted for right now. -Giri//
<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?
<fjh> ISSUE-29?
<trackbot> ISSUE-29 -- Should DAP APIs support "API Keys" -- closed
<trackbot> http://www.w3.org/2009/dap/track/issues/29
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> … 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
fjh: glad richt could make it
trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/clear// FAILED: s/Frederick, Am at work and they are testing the fire alarm. I am going to stay muted for right now. -Giri// Succeeded: s/ornot/or not/ Succeeded: s/XXX/thus we should keep the current design and close this issue/ Succeeded: s/YYY/right/ Succeeded: i/130?/Topic: Network Service Discovery - Issues Succeeded: s/dv foo/AV Transport language/ Succeeded: s/thanks richt/thanks rich, the distinction you make is useful/ Succeeded: s/PSIG/PING/ Succeeded: s/PSIG/PING/ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Default Present: Josh_Soref, fjh, +1.858.651.aaaa, gmandyam\, richt, +1.781.362.aabb, Cathy Present: Josh_Soref fjh +1.858.651.aaaa gmandyam\ richt +1.781.362.aabb Cathy Frederick_Hirsch Regrets: Anssi_Kostiainen Dominique_Hazael-Massieux Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0043.html Found Date: 24 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/24-dap-minutes.html People with action items: fjh[End of scribe.perl diagnostic output]