W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

Re: UPnP service implementing an intent

From: Dave Raggett <dsr@w3.org>
Date: Thu, 24 Nov 2011 11:14:20 +0000
Message-ID: <4ECE270C.3010104@w3.org>
To: Clarke Stevens <C.Stevens@CableLabs.com>
CC: Greg Billock <gbillock@google.com>, James Hawkins <jhawkins@chromium.org>, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, "public-web-intents@w3.org" <public-web-intents@w3.org>
On 23/11/11 18:52, Clarke Stevens wrote:
> I have the opposite problem. I know how UPnP works, but I'm just 
> learning Web Intents.
> I am becoming convinced that discovery can work much the same way it 
> does in the Opera/CableLabs API and implementation we submitted to 
> DAP. In this model, the UA does the discovery behind the scenes. When 
> the application wants to do some action, it can register an intent and 
> the UA could recognize and handle it. However, there are a couple of 
> things that I don't yet understand about Web Intents' ability to 
> handle a couple of UPnP (and other protocols) features.
>    1. Persistence  Once interaction with a device is established,
>       there is a presumed ongoing relationship with that device. For
>       example when I start playing a movie, my experience is not
>       complete. I may want to pause the moving (implying that I
>       realize it is playing and I want to pause it). I may want to
>       maintain some sort of counter in my UI to indicate how much of
>       the movie is remaining. I may want to transfer the playback of
>       the movie to a different television. I would imagine I can keep
>       track of such things as a feature of the UA or in my
>       application. Is this the expected solution?

I believe that this calls for persistent names and is related to a means 
for users to assign persistent names to services. I have written some 
thoughts on this in the wiki, see:


>    1. Events  There are numerous cases in which a device handling an
>       intent must initiate communication back to the device that
>       requested the intent WITHOUT any corresponding request. Is this
>       possible with intents? If so, what is the expected way to do this?

Does this need to be handled by the Web Intents API as such?   I could 
imagine a number of different ways for asynchronous communication from 
the service provider to the service consumer, e.g. server side events, 
web sockets, long polling and so forth. Should this be hidden by the Web 
Intents API, e.g. via providing a message port, or should it be left to 
the service consumer and provider to work out after the Web Intent has 
been bound?

Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Thursday, 24 November 2011 11:14:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC