RE: DAP-ISSUE-130 (was: Draft Minutes 21 August 2013 teleconference)

> > > <richt> ISSUE-130:
> > >
> > http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-000
> > 2/minutes-2013-07-24.html#item05
> >
> > >
> > >
> > > <trackbot> Notes added to ISSUE-130 Enable variety of protocols (e.g.
> > > UPnP, Bonour) with protocol independent developer code.
> > >
> > > richt: sent mail to list, introduces more problems to do this,
> > > especially since no commonality among the various protocols
> > >
> > JCD: I think you are missing the point: this proposal allows searching
> > for a fragment of the service type, which means something like wildcards.
> > If you request "fragment", it is like allowing a request for
> > "*fragment*" (or maybe just "fragment*" if your fragment starts with a
> > protocol prefix) Currently, you just cannot do this.
> > Which means you cannot implement a service manager web app, which
> > would explore the home network, and understand which higher level
> > services the web app can offer the user.
> > E.g. if the web app sees a phone and a TV on the network, it will
> > propose to start another web app which organizes the display of new
> > pictures from the phone on the TV.
OK. I think I now understand the use case you have in mind. I agree it's an interesting one that the current API may or may not readily supports.

> > As there are many possible services, requesting specific discoveries
> > to see of each service is currently runnable or not will be impractical.
Why is that? Wouldn't the service manager still know what specific service types the various web apps are capable of handling? The list might be long, but it wouldn't be infinite, would it? For instance, the service manager would know that a certain web app is able to use "urn:schemas-upnp-org:service:printbasic:1" and another web app is able to use "urn:vendorX-com:service:print:1". While it can perform a "fragment" search for "print", it would have no use of a local service that runs "urn:vendorZ-com:service:printpicture:1". In that case, why not search for "urn: schemas-upnp-org:service:printbasic:1" and "urn:vendorX-com:service:print:1" to begin with?

Or do you envision that the service manager would dynamically broker the discovered services to web apps without knowing what service types they support ahead of time?

> >  From a perspective of reducing the security related interactions with
> > the user, it is better that the service manager web app is given once
> > the full authority to discover everything on the network (which
> > requires wildcards or fragment search) rather than have as many
> > requests for discovery as there are services to be tested for their ability to
> run.
The service manager can easily lump all services to be tested into a single discovery request rather than issuing one request per each service. That would result in a single user interaction point for permission.

Additionally, as I stated in my earlier comment [1], it would be tricky for the UA to issue a search request for wildcard service types.

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

Regards, Cathy.


> > So 130 is not a matter of taste, and I disagree with the summary
> > judgement that closed it.
> >
> > > <Cathy> +1 on closing ISSUE-129 and ISSUE-130
> > >
> > > richt: so that proposal is not mature
> > >
> > > close ISSUE-129
> > >
> > > <trackbot> Closed ISSUE-129.
> > >
> > > close ISSUE-130
> > >
> > > <trackbot> Closed ISSUE-130.
> > >
> >
> >
> > --
> > Télécom ParisTech <
> > http://www.telecom-paristech.fr
> > > 	*Jean-Claude
> > DUFOURD <
> > http://jcdufourd.wp.mines-telecom.fr
> > >*
> > Directeur d'études
> > Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
> > 75014 Paris, France
> >
> > Site web <
> > http://www.telecom-paristech.fr
> > >Twitter
> > <
> > https://twitter.com/TelecomPTech
> > >Facebook
> > <
> > https://www.facebook.com/TelecomParisTech
> > >Google+
> > <
> > https://plus.google.com/111525064771175271294
> > >Blog
> > <
> > http://jcdufourd.wp.mines-telecom.fr>
> >
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 28 August 2013 20:38:36 UTC