Re: UPnP service implementing an intent

On Wed, Nov 23, 2011 at 10:52 AM, Clarke Stevens <C.Stevens@cablelabs.com>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?
>
>
We've talked elsewhere on this list about using Web Intents to establish a
more permanent connection. My mental model here is that what the web app
wants is a kind of "remote control" to use. While Web Intents may be good
at handing the client the remote control the user selects, it isn't really
focused on providing any detail beyond that; if there's a "universal remote
protocol" that ought to be translated to javascript messaging APIs, that's
out of scope for web intents as we've envisioned it.

For us, the sweet spot for web intents is in solving RPC-style
request-response interactions. Obviously it isn't much of a reach to extend
that to persistent service discovery, but we would like to keep the API
spec focused on this RPC-style interaction, while making certain we don't
inadvertently cripple the ability to perform persistent connection
establishment using this mechanism.

Our thinking has been that if such persistent protocols are written in
terms of messaging channels, it creates the opportunity to interoperate not
just with Web Intents, but with other web platform features that may be
useful. (I've experienced some of that flavor when Blobs Just Worked with
our prototype implementation, which allows for really exciting ideas about
transferring large data object references through the lightweight Web
Intents RPC-style method.)



>    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?
>
> Thanks,
> -Clarke
>
> From: Greg Billock <gbillock@google.com>
> Date: Wed, 23 Nov 2011 11:17:16 -0700
> To: James Hawkins <jhawkins@chromium.org>
> Cc: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, "
> public-web-intents@w3.org" <public-web-intents@w3.org>
> Subject: Re: UPnP service implementing an intent
>
> Web Intents as an API is a way for clients to request particular functions
> of generic services and receive replies (or, viewed the other way, for
> services to receive requests from arbitrary clients and provide replies).
>
> There's a mechanism in our proposal for web pages to indicate to the
> browser that they can service intents, but that is not the limit of what
> entities could participate in the ecosystem. It is equally possible for the
> browser to provide built-in services or for those services to be registered
> by and handled by OS-resident applications.
>
> I don't have a firm grasp on the scope of the use cases for home
> networking discovery, but the intents API would be sufficient to, for
> example, send a request to a particular piece of attached equipment and get
> a response.
>
> Example use case:
> A web app wanted to play a song; it could prepare an intent payload with
> the song and issue a "play" intent.
>
> navigator.startActivity(new Intent("play", "audio/mp3", song));
>
> The browser consults its UPNP directory (I know nothing about how that
> works, but presumably the browser could keep track of registered attached
> devices and their capabilities.) It finds two devices that know how to play
> MP3s and presents the user with a picker. The user chooses to play the song
> on one of them, and the song plays.
>
> I'm sure this simple example doesn't capture the full scope of the
> problem. Perhaps it shows why there is hope the problems are related,
> though?
>
>
> On Wed, Nov 23, 2011 at 9:03 AM, James Hawkins <jhawkins@chromium.org>wrote:
>
>> Can't the UA receive the broadcast of the UPnP service and add it to the
>> intent registry?  In general our model has the UA being the broker for
>> platform-level interactions with intents.
>>
>> James
>>
>>
>> On Wed, Nov 23, 2011 at 7:38 AM, Jean-Claude Dufourd <
>> jean-claude.dufourd@telecom-paristech.fr> wrote:
>>
>>> Dear all,
>>>
>>> In the Home Network TF of Web and TV IG, we discussed discovery of
>>> services, including the discovery of those services offered through
>>> existing protocols such as UPnP.
>>> I heard at the TPAC that web intents are the way to satisfy the HNTF
>>> requirements on discovery.
>>> >From reading the emails on this list, I do not see how it is possible
>>> to wrap UPnP services as intents.
>>> It seems a mediator or proxy would be needed, receiving the initial
>>> broadcast of the UPnP service announcing itself, translating that to an
>>> intent registration and sending it to the intents broker.
>>> If so, then no, web intents do not satisfy the HNTF requirements on
>>> discovery, or at least, there is a significant missing part.
>>> Best regards
>>> JC
>>>
>>> --
>>> JC Dufourd
>>> Directeur d'Etudes/Professor
>>> Groupe Multimedia/Multimedia Group
>>> Traitement du Signal et Images/Signal and Image Processing
>>> Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
>>> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
>>>
>>>
>>>
>>
>