- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Fri, 13 Jan 2012 13:12:42 +0100
- To: WebIntents <public-web-intents@w3.org>, "Matt Hammond" <matt.hammond@bbc.co.uk>
- Cc: "Greg Billock" <gbillock@google.com>
On Thu, 22 Dec 2011 17:57:14 +0100, Matt Hammond <matt.hammond@bbc.co.uk> wrote: > On Thu, 15 Dec 2011 19:24:13 -0000, Greg Billock <gbillock@google.com> > wrote: > >> Here I'm collecting my thoughts about the applicability of Web Intents >> to >> various pieces of the "Requirements for Home Networking Scenarios" >> document [1]. > From the perspective of enabling some of the HNTF use cases using > Intents, I believe RPC style Intents may make it difficult to create > good user experiences. I'm inclined to favour Intents as a means of > discovery, then establishing a communication channel: > I kind of agree but I'm wondering if the two things are really mutually exclusive. On one hand I like the idea of just discovering a service (e.g. a UPnP service) and communicate with it, like in Opera/CL (non intent based) proposal [1] On the other hand I like the simplicity of having few basic intents like "share", "view",etc that hide all the complexity for app developers. But I'm not equally sure we should abuse intents by making each single "request" to a service an intent as proposed in [2] The idea I had in mind is then more a 2 steps approach, as described in [3] I imagine the following: 1. the user browse from his PC to a page that contains a video (e.g. youtube) 2. the page shows a button that allows the user to show the video "somewhere else" (note: doesn't necessarily need to be another device, maybe just another media player on his pc). This could be done with a "view" intent. 3. The user select from a list of services being able to play the video. Here different things can happen. In the simple case, the link is just sent to the service that starts playing it. End of the story. For more complex use cases, the reply from the service contain informations that allow a persistent connection to be established. Different methods can be used as hinted in [4]. In general we could agree on few standard fields like "protocol" The benefit of this approach (I think) is that more complex use cases may be implemented on top of simple ones. The verb used is the one that triggers the use case (in this case view), after that if the application recognize in the reply something it can use (e.g. the reply say "I'm a UPnP device"), it can decide to do something with it. Otherwise it will just ignore it. What do people think? Would be nice if we could start converging on one (or a set of) solution(s), based on intents, to cover the HN scenarios and write them down in a form of spec or white paper. [1] http://people.opera.com/richt/release/specs/discovery/Overview.html [2] http://www.w3.org/mid/CAAxVY9ffaYJzeboJKAEwoFL7TFa8NA-sgK9FT7dHoBUe3XBXvg@mail.gmail.com [3] http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Opt_1_2 [4] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#persistent-connections -- Giuseppe Pascale TV & Connected Devices Opera Software
Received on Friday, 13 January 2012 12:15:50 UTC