W3C home > Mailing lists > Public > public-web-intents@w3.org > January 2012

Re: Web Intents and Home Networking Scenarios

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>
Message-ID: <op.v70uvgcz6ugkrk@giuseppep-x220>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 January 2012 12:15:50 GMT