- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Tue, 7 Jun 2011 10:55:47 +0100
- To: Dan Brickley <danbri@danbri.org>
- Cc: Matt Hammond <matt.hammond@rd.bbc.co.uk>, public-web-and-tv@w3.org, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
On 7 Jun 2011, at 10:08, Dan Brickley wrote: > On 7 June 2011 10:56, Scott Wilson <scott.bradley.wilson@gmail.com> wrote: >> I think its important not to lose sight of the "web" part. What I'm interested in is web applications/W3C widgets being able to interact with the capabilities of the TV and the content. This means that, while UPnP is quite possibly the underlying implementation, there is still a need to expose the capabilities in a way that makes sense for web developers implementing applications in HTML5 and JavaScript rather than low-level native applications directly accessing the hardware layer, which is already possible. > > Yes, Web developers can be impatient creatures. I'm not convinced that > UPnP is the right level of abstraction. > > That said, WebGL's recent adoption shows that Javascript allows fiddly > low-level APIs to be encapsulated by nicer toolkits and APIs. > > We need imho two things: an authenticated bidirectional communication > channel with media centres and devices playing that role. And then > specific collections of messages and interaction patterns with those > services. For a Web standard we can't really assume the devices are on > the same LAN; I think this will be our biggest headaches. > > Re widgets, absolutely. I worked on Joost.com's original Widget > system, which was pretty much same as W3C widgets plus some TV APIs. > It was very promising as a platform for extendding TV, ... however > those widgets were all on-screen rather than second screen, which > pretty much fails to be useful -- they get in the way of the TV! If we > can move to W3C widgets on a second screen there is absolutely huge > potential, but to do this we need that communication channel... Once > we've got a communication channel, the rest is relatively easy. Its interesting how many people I know were watching Eurovision the same way - with a laptop or mobile open with the twitter feed live. A very simple "second screen" example, but still a compelling web+tv experience. Another common example is the use of third-party TV guides to augment the EPG - which doesn't have things like social content, reviews, actor bios etc. I think these types of UCs are easy to explain in user terms, and shouldn't be that challenging to implement in a more connected way without delving into UPnP territory. In terms of the channel, can we make use of legacy communication channels? For example, if a widget want to trigger a change of channel on the primary screen, then there is the pairing of the device with the TV to act as a controller, and then also the user granting the widget access to the channel-switching API <feature>. The latter could be handled as per DAP and WAC[1]. > > cheers, > > Dan > > >> PS I would take a look at the CEA web binding, but like most web developers I won't spend $450 on a spec document :) > > Well, quite. [1] http://specs.wacapps.net/2.0/feb2011/core/widget-security-privacy.html
Received on Tuesday, 7 June 2011 09:56:19 UTC