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

Hi,

On 8 Jun 2011, at 02:43, KOMATSU Kensaku wrote:

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

+1

> 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.

There are perhaps two separate angles on "how to deliver".

A connected device can, in this context, be "thick" or "thin" — a "thick" device can deliver the data itself to nearby devices, while a "thin" device only has an identifier (e.g., a URI) for the content, which it can make available, but which can be used to retrieve rich data from an Internet-based service as needed. (Indeed, there's no reason why one can't be a strict superset of another: i.e., you can always get an identifier, but some devices are capable of providing more detailed data from the outset as well to save having to retrieve it oneself) — this potentially reduces the barrier-to-entry for the hybrid devices in that as a a minimum they only need to be able to construct or retrieve an identifier (which they should be able to do from the over-the-air or recorded metadata) and relay it to devices on the LAN.

The operation of 2s scenarios with the "thin" devices is obviously dependent upon those identifiers being resolveable in some fashion, of course.

An extension of this would be in including those same identifiers in EPG data, so that 2s devices can look forward/back in the schedules, or at programmes on other channels, and retrieve rich data for those, too. It's not hard to envisage a whole range of possibilities based upon these relatively straightforward principles.

M.

Received on Wednesday, 8 June 2011 10:36:28 UTC