RE: Web Intents and Home Networking Scenarios

Giuseppe Pascale wrote:
> Sent: Friday, January 13, 2012 7:13 AM
> To: WebIntents; Matt Hammond
> Cc: Greg Billock
> Subject: Re: Web Intents and Home Networking Scenarios
>
> 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?
>
I like this idea. It looks like a good approach to support the both types of 
usages.

> 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

>
> [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