- From: Greg Billock <gbillock@google.com>
- Date: Thu, 15 Dec 2011 11:24:13 -0800
- To: WebIntents <public-web-intents@w3.org>
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