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.org/discover","href":"/control.html","title":"Living
room TV","disposition":"background"},{ ...2nd service...},{...3rd
service...}]

where a single header lists the service descriptions.

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.

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?

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.

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.

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

Received on Wednesday, 16 May 2012 09:29:06 UTC