On 8 Jun 2011, at 11:35, Mo McRoberts wrote: > 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. Interesting - sounds a little bit like how oEmbed works: http://oembed.com/ > > M. > >Received on Wednesday, 8 June 2011 10:42:02 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:05 UTC