Re: Web Intents and Home Networking Scenarios

Greg wrote:
> 4.1 - General Requirements
> 4.2 - Discovery and Advertising
> The negotiations with UPnP and other home networking protocols
> is the province of the user agent.

I think we should note that "user agent" is defined as "the user agent
and extensions / plug-ins", it doesn't necessarily mean the precise
binary that was shipped on day 0, but it is more or less "trusted code
running on the system" as opposed to "web content".

> Web Intents as an API exposed to web apps doesn't deal with
> this.

> There's an interesting point to make on 4.2.4 (Content Advertisement).
> This kind of "pick" functionality may be serviced by Web Intents,
> in the sense that an application selecting content to play on a TV,
> for example, might want to pick videos stored in a cloud service and
> available through a Web Intents API.

> In that case, though, that TV-based application is acting as the
> user agent, and can simply implement the Web Intents API, thus allowing
> the web application surfacing that video content to be registered and
> supply that functionality.

This covers the 2 box model. For 4.3.5 (3 Box Model), if the Intents
UA is a typical computer and the TV is a UPnP service, then the UA or
the UA with an extension/gateway for UPnP expose the "play"
functionality and the web application would do "pick" as you described
above.

> and the user agent can realize there's an outstanding action on the stereo and
> default the delivery to that device through the proper networking protocols.
> (timeless talked about this in [2])

yay!

> Another way to think about this, though, is by providing tokens to the web
> application by the user-agent-supplied discovery intent handler, which the
> web app can then use to hint the user agent on delivery.

Yes, I think i tried to hint at this somewhere. It's also
unfortunately possible that I haven't posted it yet (I have a queue
which I had hoped to post this month, but it looks like I'm going to
run out of time).

> This might look like this:
...
I think this is a case where my pluggable hubs would come in.
One approach:
action="hne/play"
type="video/mpeg1"
The system has the data you listed:
> { "DVD Player" :
>  { type: "dvd",
>    name: "Toshiba DVR620 - DVDr/ VCR combo",
>    controls: [ "hne/pause",
>                "hne/mute",
>                "hne/rewind",
>                "hne/fast-forward",
>                "hne/skip",
>                "hne/toshiba/copy-vcr-to-dvd",
>                ] },
>  "Living Room TV" :
>  { type: "tv",
>    name: "LG - 47LW5300 - 47" Class ( 46.9" viewable ) LED-backlit
> LCD TV - 1080p",
>    controls: [ "hne/mute",
>                "hne/volume-up",
>                "hne/volume-down",
>                ] }
> }

And the picker shows:
- DVD Player
Automatically use:  [x] Pause [x] Mute [x] Seek [ ] Copy vcr to dvd
- TV
Automatically use:  [x] Mute [x] Adjust volume

The user can check/uncheck options and clicks one of DVD Player or TV.

What's returned is an Intent for "hne/play" (mapped to DVD Player/TV)
and the system remembers that the user has authorized a couple of
things.

> For example, muting the DVD player could be invoked as:
> action="hne/mute"
> type="hne/device"
> data={device: "DVD Player"}

As long as the {device: "DVD Player"} is really:
{Opaque IntentObject #1} [UA maps IntentObject #1 to {device: "DVD Player"}

> 4.4 - Application transfer

This sounds like it might be sending a bookmark, you can use the
"Share" intent :)

But yes, it's mostly out of scope, although a User Agent may offer
access to running tabs using Intents on its local network.

Modern UAs are starting to do some of this already (Firefox Sync and friends).

> We've discussed exchanging MessagePorts for notifications, which is possible,
> but it's an exception to this pattern.

While it's a possibility, i'd like to avoid it. RPC style is preferable.
For something like a light switch and wanting to monitor its state, i
think one could use a rather simplistic approach:
action="hne/get-state"
type="hne/device"
Returns the current state
action="hne/get-state-change"
type="hne/device"
data={Opaque IntentsObject for device from before}

which is asynchronous and only fires when the switch is toggled. If
you then want to listen to it again, you trigger the intent again. The
hne/ gateway can ensure that if it has a client listening it buffers
toggles (in case someone turns the switch on and off repeatedly while
the system is dispatching the first change reply).

> U4: while it is possible to imagine user agents cooperating in this way, it
> is outside the scope of web intents.

Agreed, if a bunch of clients want to vote, they should use an app
that manages voting using typical client/server systems.

Otherwise it's pretty easy for someone to have an app that cheats.
(Just as people went to school with watches that could turn off the
teacher's tv.)

> U15-U18 are in the sweet spot for intents.

Agreed

Received on Friday, 23 December 2011 01:18:21 UTC