Re: Motivation for BBC use cases (was Re: webtv-Issue-20: TV Querying and Control)

Hi,

I'm apologize if my senario shown below is not suitable for this
thread and HNTF.

I think second screen senario has to consider about not only
controlling each other
but also how to get real-time tv data ( such as tracking data of so ).

I think people doesn't want only tv relevant widgets, they also want to google
web contents which is relevant to tv program ( shopping item, travel
information,
nice restaurant etc). To achieve it smooth way, I think those two points shown
below are worth to consider.

1. data format ( describing detailed TV program. I guess WebVTT is candidate
for it, but I don't see current spec is enough or not )
2. how to deliver ( I mean server-push technology, such as Comet or WebSocket,
But scaling the service needs other communication methods, UDP based technology.

Cheers,

---
Kensaku KOMATSU
NTT Communications.

2011/6/7 Scott Wilson <scott.bradley.wilson@gmail.com>:
>
> 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 Wednesday, 8 June 2011 01:44:17 UTC