Web Intents and Home Networking Scenarios

Here I'm collecting my thoughts about the applicability of Web Intents to
various pieces of the "Requirements for Home Networking Scenarios"
document [1].

Summary: I think while Web Intents is an appropriate technology for some
of the scenarios in the document, there are many which are out of scope
and are better addressed by other web platform features and delegated
to technology in the user agent.

Overall philosophy: Web Intents in the home (media) networking environment
is about providing a way for web-resident applications to control that
equipment. It has very little to do with how the user agent itself manages
the equipment. It is up to the user agent to take the interactions with
that equipment and package them for consumption by web applications. This
is reminiscent of how web apps just write <a href="http://www.example.com">
to navigate. Web apps don't have to negotiate DNS, deal with ssl key
revocation, ask for SafeBrowsing information, negotiate TCP/IP establishment,
HTTP parsing, etc. The user agent is taking a complex network environment and
packaging it for much simpler consumption by web apps.

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

4.3 - Control and communication

Web Intents can provide such control functions to web applications. The role
of the Web Intents API is more generic, but we can imagine a set of
action/type intents which would address these requirements. The limitation is
that Web Intents are user-initiated and RPC-style.

This makes it easy to perform some needed operations, but others which rely
on persistent connections need more thought.

So for example, imagine an intent to get a list of available equipment:

action="hne/list"
type="text/plain"

Which might return a list of names back:
Toshiba DVR620 - DVDr/ VCR combo
LG - 47LW5300 - 47" Class ( 46.9" viewable ) LED-backlit LCD TV - 1080p
...

(Better-formatted lists can be imagined, this is just a placeholder
illustrating data flow.)

One way to manage the desire for a persistent connection is to postulate
that the user agent, through clever defaulting, can pass further controls
to the device that makes sense. For example:

action="hne/play"
type="audio/mp3"

which the user directs to a stereo. Then subsequently, the user launches
another intent:

action="hne/pause"
type="text/plain"

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])

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. This might look
like this:

action="hne/list"
type="hne/device-list"

returns:

{ "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",
                ] }
}

Note that this puts the user firmly in control of what kinds of configuration
and control are granted to each app. For example, the user may not want to
give a particular app the ability to use the TV, but allow the ability to use
the stereo. (Or the permissions may not make sense.) Sophisticated users with
complex setups have the ability to arrange arbitrarily complex assemblages of
controls and aliasing with the help of the user agent, like routing the "TV"
mute control to the amplifier they have hooked up to it and things like that.

So the web intents framework, by putting the user in the loop, allows for very
sophisticated permissioning and configuration control which is then presented
to the web app as a very simple C-style object invocation paradigm. For
example, muting the DVD player could be invoked as:

action="hne/mute"
type="hne/device"
data={device: "DVD Player"}

This allows the user agent to examine the payload, since it is always in the
loop, and apply policy choices set by the user. So for instance, controls
like this can be routed to the named device without interrupting the user
at all, allowing the web app to display nice UI showing what the control
state of known devices is, and not requiring any particular protocol
sophistication on the part of the web app.

There's even a possibility for extension intents to be surfaced. I invented
a vendor-specific intent above. You can imagine either metadata accompanying
such vendor-specific intents, or other methods of querying metadata about
them, such that the web app can present such controls in data driven ways
allowing for extensible control of the equipment.


4.4 - Application transfer

This is outside the scope of Web Intents. It sounds better addressed by
lower-level user agent capabilities.

4.5 - Security and Privacy

The Web Intents spec will do a good job of limiting access to equipment
to trusted applications. By restricting any access to user-initiated
actions requiring explicit approval, the user is always in the loop.
The all-local nature of the data transfer ensures that no information
is transferred outside the network.

--------------------

The details above are meant just as placeholders which illustrate the kinds
of data flows and persistent control connections we could develop using
the Web Intents API. The big features that stand out to me are that putting
the user in the loop for discovery really allows very powerful and
sophisticated modeling by the user of their equipment and the availability
of it to various web applications. This is left basically completely up to
the user agent, which means that user agents can focus on locally important
goals and can abstract a lot of the implementation nitty-gritty away from
the web applications.

Going through the use cases, many of them are met by this framework, but
not all. For example, U1: getting messages from a discovered service. This
is harder to fit into the RPC-style control model that Web Intents uses.
We've discussed exchanging MessagePorts for notifications, which is possible,
but it's an exception to this pattern.

Service migration might be addressed by a state query intent, which could then
be used to populate the application as migrated over to a new user agent. I
think this is mostly out-of-scope for web intents, though. The same goes for
U4: while it is possible to imagine user agents cooperating in this way, it
is outside the scope of web intents.

The time synchronization use cases also need some kind of notification channel
which doesn't fit the model as well. Perhaps a time-synchronized pseudo-device
can fit the model if the user agent knows how to construct one...

Linking web applications (U14) is definitely an area where web intents can
be relevant, but the scenarios listed are not unique to home networking
eqiupment. It is more useful to imagine applications built on top of web
intents where the action="share" type="picture" can be handled by an
application a friend is running, and they see it whether or not they are on
the local network.

U15-U18 are in the sweet spot for intents. The various list and control
actions fit very nicely into the above model. the focus is on how the user
agent allows web apps to have control over, and be sources for, various
home network media equipment.


[1] http://www.w3.org/TR/2011/NOTE-hnreq-20111201/

[2] http://lists.w3.org/Archives/Public/public-web-intents/2011Dec/0013.html

Received on Thursday, 15 December 2011 19:24:42 UTC