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.

>> 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 Friday, 20 April 2012 20:15:15 UTC