RE: Web Intents and Home Networking Scenarios

Hi Greg,

Comments inline below.

Regards
  Claes

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: den 15 december 2011 20:24
> To: WebIntents
> Subject: 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. 

I completely agree on the view that Web Intents has little to do with how interaction with equipment on lower levels are managed. However, we have to consider how much of these lower levels that have be a part of the user agent implementation and how much that could be implemented as part of external Service implementations. Ideally a de-coupling between the user agent and specific low level services discovery protocols would be preferable. However, that may not be possible to achieve. I am not very familiar with UPnP but as far as I understand UPnP service discovery builds on receiving broadcast messages over UDP. So a Web Intents based Service implementation, which is a web application, for a service on a device discovered through UPnP must have access to UDP. This means user agent additions or another solution, for example an internal web server that implements UPnP service discovery. 

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

Ok, so this is an alternative to the approach that has been discussed before where an HTML5 MessageChannel is used for running a high level "TV control protocol" meaning that the Service selected by the user for the action="hne/list" by default is the target for the subsequent actions? If I interpret your proposal correctly I get a bit confused as it extends the Web Intents semantics from service discovery to a sort of "control protocol". I assume that you mean that actions "hne/play" and "hne/pause" will not cause the UA to pop up a service selection window as the "default Service" was selected by action="hne/list"?
 
> 
> 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.

All above looks like a nice proposal but, if I interpret it correctly, this also seems changing/extending the original purpose with Intents.

> 
> 
> 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 Monday, 19 December 2011 11:33:44 UTC