RE: exploration of non-web intent providers

See inline below.

Claes

> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org]
> Sent: den 20 april 2012 22:15
> To: Jean-Claude Dufourd
> Cc: public-web-intents@w3.org
> Subject: Re: exploration of non-web intent providers
> 
> On 20/04/12 16:07, Jean-Claude Dufourd wrote:
> >>> REQ4: Device1 MUST have an http server running somewhere to put the
> >>> registration and service pages.
> 
> >> I wasn't sure whether REQ4 is needed for your option 2.
> 
> > JCD: Where do you store the service page managing the intent provided
> by
> > the Device2, service page which in option 2 is generated by an entity
> on
> > Device1 ?
> 
> Our models are different, and in my case there isn't a service page as
> such, but we could choose to expose the UPnP service description to the
> web app after the user has selected device2. That is a matter of how
> much we choose to support abstraction layers that hide whether the
> service was discovered via UPnP or ZeroConf etc.

We are prototyping Web Intents for Services in UPnP devices, i.e. "device 2" in the context of this discussion, and have chosen to expose the Service as web page that could be visible or "hidden". 

Device 2 contains:

- A web server
- Service page
- UPnP description document containing the registration markup according to http://www.w3.org/wiki/images/f/fa/W3C_Web_Intents_-_Local_Service_Discovery.pdf

So the UA's Web Intents implementation, i.e. our own Web Intents JS shim, will:
1. Use our browser's UPnP API and discover UPnP devices indication service type "WebIntents" in an SSDP header.
2. Load the UPnP description document
3. Read the Intent Service registration markup in the SSDP description document and register the Service

We are also discussing options. It might be better in the UPnP description document to just have a URL to a Service registration page. This would be more flexible and allows for JS in the registration, which might be an option according to the discussion in WHAT WG. See the thread starting at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-April/035301.html . 

Another option is to include Action and Type in an SSDP header. The motivation is that in a network with many Web Intents enabled UPnP devices it would not be necessary to download the UPnP description document for all discovered Web Intents enabled devices in order to find matching Action and Type. 

> 
> >> I experimented with chromium browser extensions as a means to
> implement
> >> Web Intents along with UPnP.*This is surprisingly tricky, and
> indicates
> >> the need for a simply means to couple web intents to trusted browser
> >> extensions*. I am hoping to explore extending webkit to support this
> over
> >> the next year.
> 
> > JCD: This is the reason behind my proposal.
> > If nothing is standardized, then doing this UPnP link will be highly
> > dependent on the browser, whereas if the UA itself is a UPnP service,
> with
> > the service description I propose, then interface with the UA is the
> same
> > as interface with other services, and it will work across browsers.
> 
> If we want browsers to work with today's UPnP devices, then there will
> need to be some client side code that understands UPnP advertisements
> and the associated service descriptions.
> 
> For the intent matching to work there would need to be a map from the
> intent names e.g. for TV and print to the corresponding UPnP
> terminology. Given that, it doesn't seem unreasonable to do the next
> step and expect the UA to connect the services via message ports.
> 
> Another way to extend the browser without having to update its code
> would be to make use of a local device server, such as is proposed by
> webinos. The local server could register a bunch of services with the
> user agent. This leaves open the question of informing the web intent
> system that an given intent provider offers a message service rather
> than a web page that the browser needs to load. That sounds to me like
> information that would be provided through the registration mechanism.
> 
> The web intents registration mechanisms seems a little vague to me at
> this point. I understand how an intent provider could be registered if
> you as the end user visit the associated website. However, what about
> when you need to search for intent providers. Do we have a better
> solution that using a regular search engine and following the links it
> returns one by one? That is putting a big burden on end users! When it
> comes to local discovery, the notion of a registered intent broker is
> interesting. The browser would ask that broker for intent providers
> matching a given intent. The webinos local server (aka PZP) could act
> as
> an intent broker. It is certainly worth thinking about.
> 
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Monday, 23 April 2012 12:00:47 UTC