- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 10 Nov 2011 17:15:46 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- CC: Robin Berjon <robin@berjon.com>, public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Dominique Hazael-Massieux wrote: > Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : >> Hi >> a.) to register a URL endpoint as an intent provider the user must visit >> a web page (presumably hosted by the target device itself) and capture >> the intent registration from that page before that intent provider can >> be used within the UA. > > My understanding is that this is not a MUST at all, but the way > Web-based services can be added by a user. > > For a local network approach, my take would be that the browser would be > doing the discovery, and possibly offer the user to add local services > to the list of available providers when such a service matches the > requested intent. > > Typically, a "gallery" intent (i.e. requesting a list of medial files) > would make the browser list local media galleries (from UPnP) in > addition to the registered Web services (e.g. your on-line photo > albums). This works for me. > >> b.) to then subsequently use a registered intent provider the concept is >> to open that provider, again as a web page in a seperate tab within the >> UA. From here we can then establish a bi-directional web messaging >> channel on which we can send and receive messages to communicate to and >> from that web page that is representing the current local service. > > I think the Web-page-in-a-separate tab is also an optional aspect of Web > intents; the browser could serve as a broker between the local-network > service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. > >> Perhaps someone could take the time to describe exactly how a user could >> communicate with an existing TV device in their home from a web browser >> supporting web intents based on the above requirements? > > Here is a rough sketch: > * user hits a Web page that wants to load a picture from his gallery > * that Web page asks for an intent for media gallery > * the browser shows to the user the list of services that can provide > media galleries; having detected that there are such services on the > local network, it includes these services in the list > * the user wants to pick a picture from the gallery hosted on his TV, so > picks the TV set in the list of services > * from then on, the browser turns the messages sent by the Web page via > postMessage() into UPnP requests that the TV set can respond to, and > also turns the responses into messages that the Web page can deal with. This also has the potential of working. We might need to allow a web page to perform pass-through messaging in the format it wants. If we have a bi-direcitonal channel between a service endpoint and the user agent then I guess we could push whatever we needed over that (e.g. json, protobufs, key/value sets, xml, etc)...or the UA could abstract some of that away if we could find a reasonable model for that. > > Dom > Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. - Rich
Received on Thursday, 10 November 2011 16:16:24 UTC