- From: Dave Raggett <dsr@w3.org>
- Date: Fri, 20 Apr 2012 21:14:49 +0100
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- CC: public-web-intents@w3.org
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