Re: UPnP service implementing an intent

On Wed, Nov 23, 2011 at 4:11 PM, Greg Billock <gbillock@google.com> wrote:
> We've talked elsewhere on this list about using Web Intents to establish a
> more permanent connection.

I'm hoping that the permanence is the object that the Client receives
from the UA when it creates an Action (and the user selects a Partner
Provider).

> My mental model here is that what the web app wants is a kind of "remote control" to use.

That seems about right

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

I'm hoping it doesn't need more.

Consider a basic tv remote.

1. Client new <channel-controller> Action
2. User selects a TV which supports being controlled.
3. Client sends <set Channel = 4> to that Action
4. TV receives this and does something
5. Client sends <set Channel = 7> to that Action
6. TV receives this and does something
7. the user decides to change the target for this action from the TV
in the family room to the Cable box. Neither the Old Partner Provider
nor the New Partner Provider nor the Client are told of this.
8. Client sends <set Channel = 9> to that Action
9. Cable box receives this and does something


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

>From my perspective, <channel-controller> is an Action, and it's
clearly not an Action that this TF needs to define. If someone wants
to make a JS API wrapping using this action, that's also fine, and it
too is out of scope. But the goal should be to enable this to work.

Most likely what will happen is some UPnP gateways will be responsible
for having the ability to map the channel-controller Action into some
UPnP commands. And again, that's definitely out of scope, but it's
also wouldn't be hard for someone in UPnP space to understand how to
implement that, it's considerably simpler than having to figure out
how to write C++ / Flash / Java code to integrate UPnP into a web
browser (which is something none of us want them to do).

> For us, the sweet spot for web intents is in solving RPC-style request-response interactions.

sure

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

right

> 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'm afraid that Message Channels make it way too easy for people to
write complicated protocols where there will only ever be one
provider. Hence my preference for Intents only.

Received on Wednesday, 23 November 2011 21:48:37 UTC