RE: Web Intents and Home Networking Scenarios

Hi Greg, 

Comment inline below.

Regards
  Claes

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: den 20 december 2011 20:21
> To: WebIntents
> Subject: Re: Web Intents and Home Networking Scenarios
> 
> On Mon, Dec 19, 2011 at 3:33 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonyericsson.com> wrote:
> > 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"?
> 
> Right. My goal was to see how close we come "out of the box" with a
> simple RPC-style interaction to satisfying the various use cases, and
> see where the gaps are that would need a persistent connection.
> 
> The idea would be to use the Web Intents API, and layer the control of
> stereo/TV gear on top of it. I think this accomplishes many use cases
> (and I suspect they are probably the most common ones), but there are
> some it doesn't really handle directly as an RPC style architecture.
> I'm not sure how important those use cases are for the ecosystem. If
> they're really important, we should think about whether using Web
> Intents strictly as a discovery mechanism is the right way to go. If
> they're more peripheral, then perhaps this kind of advanced use can be
> left for exceptional cases and a more RPC-style interface layered on
> top of the most natural use of Web Intents is the way to go for the
> main feature set.
> 
> What's your view of the relative importance of the use cases, and
> whether it makes sense to separate them like this? (I suspect the
> user-facing impact would be that some simple apps wouldn't make use of
> it at all, or that for more sophisticated apps users might face an
> additional permission-granting step for advanced functionality.)

I think that the type of use cases you describe, for example discover a TV or stereo gear on your mobile phone and use it as a remote control, are important. Your suggested approach on including "control actions" for common use cases in Web Intents is tasteful in the sense that it is a way to make it easy for application developers to implement common tasks according to the principle "make it easy for developers to do things they often do and make more seldom tasks possible".  However, it is a big decision if we want to break the architectural principle that Web Intents is a pure service discovery mechanism. 

I currently don't have a definite opinion here. It would be interesting to hear others view.

> 
> 
> >>
> >> 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 Wednesday, 21 December 2011 16:50:35 UTC