RE: Web Intents for local network services (DAP Action-510)

Thanks for your feedback Dave! See my responses inline below.

Claes

> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: den 16 maj 2012 11:29
> To: Nilsson, Claes1
> Cc: public-web-intents@w3.org
> Subject: Re: Web Intents for local network services (DAP Action-510)
> 
> Hi Claes,
> 
> I like the new proposal. The concept of a hidden background page is
> analogous to the background pages in chrome extensions, and can provide
> a mapping from a generic (standardized) API to the specifics of a given
> device.
> 
> In your slides you showed an intent description in the SSDP response
> headers. If a device supported multiple services, we need something a
> little more flexible.
> 
> One suggestion would be to use an JSON encoded description, e.g.
> 
> X-WebIntents:
> [{"action":"http://webintents.org/discover","type":"http://webintents.o
> rg/discover","href":"/control.html","title":"Living
> room TV","disposition":"background"},{ ...2nd service...},{...3rd
> service...}]
> 
> where a single header lists the service descriptions.

Spontaneously this looks like a good proposal. We will consider this.

> 
> SSDP imitates HTTP but over datagram sockets. This constrains how long
> the response can be before packet fragmentation and reassembly occurs,
> but a typical MTU of 1500 bytes without fragmentation suggests that the
> above approach would allow devices to advertise several services
> without
> problem. To allow this to scale further, there could be a separate
> header that references a description file that can then be obtained via
> HTTP over TCP/IP, e.g.
> 
> X-WebIntents-ref: /services.json
> 
> The two headers could be used together, to describe the most common
> services directly in the SSDP response for network efficiency, and the
> full set of services in the referenced description file. Note that the
> description file could use the same format as above, or we could
> propose
> extensions to the UPnP Device Description format. However, I suspect
> from a standardization perspective, that it would be easier to avoid
> extending the UPnP Device Description format.

Do we have to add this complexity to handle the rare cases of so long response packets? If those situations are rare can't we live with the slower responses in those rare cases caused by packet fragmentation and reassembly? Or am I not forward looking enough?

> 
> Did you consider a means to query for a specific intent, i.e. to be
> able
> to name the intent in the multicast SSDP query?

Yes, we have considered a more detailed granularity, i.e. including Action and Type, for the searched Web Intents Service in the ST-header of the SSDP M-SEARCH request. However, we decided to keep it simple for now. But we will consider including Action and Type in the header.

> 
> A further topic for discussion is how to support legacy UPnP devices.
> 
> We are both assuming that the browser has a web intents manager that
> deals with registration of services. This manager would be responsible
> for sending the extended SSDP queries and registering services
> described
> in the extended headers in the SSDP responses. Now imagine a browser
> add-on that handles the legacy SSDP responses. The add-on would
> retrieve
> the UPnP description files via HTTP, and register the web intents
> services with a binding to the corresponding background pages supplied
> as part of the add-on. I can imagine some kind of browser internal URI
> scheme for accessing resources held within browser add-ons.

Yes, support for existing legacy UPnP devices is important but we don't address this in our current proposal. I have got the impression that Opera and CableLabs is working on a proposal for legacy UPnP devices.

> 
> Finally, some services may be subject to access control, perhaps for
> parental control, or to limit access to device with expensive
> consumables (a fancy printer). The web intents manager will need a way
> to ask for the corresponding credentials when using background pages.

This is a good point. Generally each Web Intents Service provides it's own security such as login with credentials but if we have background pages that require login this is an issue. This is one of the issues with background Services. Another issue is to clearly make the user aware that a background Service is running. I have a DAP action on this, http://www.w3.org/2009/dap/track/actions/519, and I will provide input based on prototyping we are doing.

> 
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Wednesday, 16 May 2012 14:33:53 UTC