- From: Matt Hammond <matt.hammond@rd.bbc.co.uk>
- Date: Tue, 21 Jun 2011 15:00:44 +0100
- To: "Igarashi, Tatsuya" <Tatsuya.Igarashi@jp.sony.com>, "Scott Wilson" <scott.bradley.wilson@gmail.com>, "Web and TV Interest Group WG" <public-web-and-tv@w3.org>, "Mark Watson" <watsonm@netflix.com>, "Giuseppe Pascale" <giuseppep@opera.com>
Yes, I can confirm that I am not proposing a specific application protocol, but instead just providing a concrete scenario for which it ought to be possible to create an application specific protocol over the connectivity that work here might define. My intention was to provide a scenario that would involve communication other than media content sharing/pull/push. regards Matt On Tue, 21 Jun 2011 14:22:07 +0100, Giuseppe Pascale <giuseppep@opera.com> wrote: > On Tue, 21 Jun 2011 12:40:45 +0200, Mark Watson <watsonm@netflix.com> > wrote: > >> This is an interesting issue, but I would say that it is essential to >> distinguish connectivity from application protocols. >> >> Establishing connectivity between applications is one thing. There are >> problems here of application discovery over the local network, security >> and connection establishment that will need to be addressed. >> >> The actual protocol which is then used over this connection is a >> totally orthogonal concept. It's application-specific and those >> application protocols may be used in other contexts as well (for >> example, the smart phone quiz app might use the same quiz protocol to >> interact with the quiz app on the TV as it would use to interact with >> the broadcaster's servers, in the case that the TV does not support >> that quiz app). >> >> I'm not saying that the group should not work on both - though I'd be >> skeptical about standardizing a universal quiz protocol - but they >> should certainly be handled separately. >> > Agree and in fact I don't think the use cases is suggesting this (but > Matt can confirm). > In general we seems to have 2 general use cases: > > - communicate with services using existing and established protocols > (UPnP, Bonjour, etc) > - enable communication between 2 applications with a "proprietary" > protocol > > Both are of interest, The challenge here is we can identify a common > architecture to cover both. > > On top of this some specific services/usecases may suggest the creation > of a more specific API/protocol well integrated in the web platform > while some other (like the quiz example) nwill probably never require an > ad hoc solution. > > My proposed way forward is to start the first part (general framework) > leaving the discussion on add hoc protocols/APIs for specific services > as a second stage discussion. > > /g > > >> ...Mark >> >> On Jun 21, 2011, at 10:11 AM, Matt Hammond wrote: >> >>> Hi, I have attempted to reformulate the 'quiz' use case as you >>> suggested: >>> >>> """ >>> User Scenario: Interactive quiz >>> >>> Alice and Bob operates the TV device to watch a quiz programme, from >>> live >>> broadcast. >>> >>> Alice and Bob also operate their smart phones to access a quiz >>> application. >>> >>> The smart phone quiz application knows that the quiz programme is being >>> watched on the TV and establishes communication with an interactive >>> application on the TV that is active during the quiz programme. >>> >>> The TV application overlays on-screen information informing Alice and >>> Bob >>> that they are now taking part in the quiz. >>> >>> As a question is asked in the quiz programme, the interactive TV >>> application instructs Alice and Bob's smart phone quiz applications to >>> ask Alice and Bob the same questions. Alice and Bob enter answers to >>> the >>> questions using their smart phones, which are relayed back to the >>> interactive TV application. >>> >>> Between quiz rounds, Alice and Bob's scores are displayed on their >>> smart >>> phones and overlayed on screen by the TV interactive application. >>> Scores >>> are compared to those of the contestants featuring in the programme. >>> """ >>> >>> Regarding need/justification: Using local-link communication to an >>> interactive application provided as part of a broadcast stream >>> provides a >>> way around scalability concerns if participation is substantial for a >>> particularly popular programme. >>> >>> >>> regards >>> >>> >>> Matt >>> >>> >>> On Wed, 08 Jun 2011 06:12:35 +0100, Igarashi, Tatsuya >>> <Tatsuya.Igarashi@jp.sony.com> wrote: >>> >>>> Hi Matt and Scott, >>>> >>>> I am happy to include more user scenarios in the use case description. >>>> (I meant "use case" as http://en.wikipedia.org/wiki/Use_case ) >>>> >>>> Would you re-write it as a scenario from user perspective? This makes >>>> us >>>> easy to understand. >>>> >>>> Thank you. >>>> >>>> -***---***---***---***---***---***---***---***---***--***---***---***- >>>> Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com) >>>> NS Development Dept. Technology Development Group >>>> Sony Corporation >>>> (Voice) +81-3-5435-3252 (Fax) +81-3-5435-3274 >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com] >>>>> Sent: Tuesday, June 07, 2011 11:06 PM >>>>> To: Matt Hammond >>>>> Cc: Web and TV Interest Group WG; Igarashi, Tatsuya >>>>> Subject: Re: webtv-ISSUE-24 (igarashi): Local Link of web >>>>> applications >>>>> [HOME_NETWORK_TF] >>>>> >>>>> >>>>> On 7 Jun 2011, at 14:29, Matt Hammond wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is an interesting use case and set of scenarios. I believe it >>>>> will >>>>> be important to enable communications between interactive >>>>> services/applcations on a TV and other devices in a manner perhaps >>>>> along >>>>> the lines you suggest. >>>>>> >>>>>> I have an old-style use case that perhaps could be incorporated into >>>>> your >>>>> list of scenarios (with a little rewriting): >>>>> >>>>> I quite like these old-style use-cases as they make a lot more sense >>>>> when >>>>> explaining what we are trying to achieve. >>>>> >>>>> Quiz programmes are one example, as are competition shows of the >>>>> "-idol" >>>>> variety - though today many of these make use of text >>>>> messaging/telephony >>>>> charges for their business model, and so to replace this >>>>> functionality >>>>> with >>>>> web APIs would also require either access to micropayment >>>>> functionality, >>>>> or a bridge from TV to telco services. >>>>> >>>>>> >>>>>> """ >>>>>> Scenario: enabling interaction between companion content and >>>>> television >>>>> interactive services >>>>>> >>>>>> One or more companion devices can communicate with an interactive >>>>> widget, >>>>> application or service on the television. For example: a quiz >>>>> programme >>>>> may feature an interactive service to allow users to play along. >>>>> Users >>>>> each >>>>> use their own individual companion device to participate in the >>>>> quiz, in >>>>> time with the programme as broadcast. As the programme progresses, >>>>> questions >>>>> are presented to the users on their companion device at the same >>>>> time as >>>>> the contestant in the programme has to answer them. Scores are >>>>> compared >>>>> and collated on the television screen at points throughout the quiz. >>>>>> """ >>>>>> >>>>>> There may be some overlap between this and issue-4 or issue-12; >>>>> however >>>>> I believe there is probably a difference, since the scenarios focus >>>>> on >>>>> applications spread across several devices working together, rather >>>>> than >>>>> migration, or the wholesale remoting of a UI. >>>>>> >>>>>> From our perspective at the BBC, it would be great if the scope is >>>>> widened >>>>> such that one of the applications may not necessarily be a web >>>>> application >>>>> but which still, in some way, exposes a service with which web >>>>> applications >>>>> could communicate. In the UK for example, interactive applications >>>>> delivered as part of the TV broadcast on many of the platforms these >>>>> will >>>>> not be web based for the forseable future. >>>>> >>>>> I think being able to support the migration of current "red button" >>>>> interactive content to the open web and web applications/widgets is >>>>> an >>>>> excellent objective to work towards. >>>>> >>>>> >>>>>> >>>>>> regards >>>>>> >>>>>> >>>>>> >>>>>> Matt >>>>>> >>>>>> On Tue, 07 Jun 2011 11:11:28 +0100, Igarashi, Tatsuya >>>>> <Tatsuya.Igarashi@jp.sony.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Sorry for the bad link. >>>>>>> >>>>>>> Here is the correct link to the use case description. >>>>>>> >>>>> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Loc >>>>> alLink#Use_Case:_Local_Link_of_Web_Applications >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>> -***---***---***---***---***---***---***---***---***--***---***---***- >>>>>>> Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com) >>>>>>> NS Development Dept. Technology Development Group >>>>>>> Sony Corporation >>>>>>> (Voice) +81-3-5435-3252 (Fax) +81-3-5435-3274 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: public-web-and-tv-request@w3.org >>>>>>>> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Web and TV >>>>> Interest >>>>>>>> Group Issue Tracker >>>>>>>> Sent: Tuesday, June 07, 2011 7:05 PM >>>>>>>> To: public-web-and-tv@w3.org >>>>>>>> Subject: webtv-ISSUE-24 (igarashi): Local Link of web applications >>>>>>>> [HOME_NETWORK_TF] >>>>>>>> >>>>>>>> >>>>>>>> webtv-ISSUE-24 (igarashi): Local Link of web applications >>>>>>>> [HOME_NETWORK_TF] >>>>>>>> >>>>>>>> http://www.w3.org/2011/webtv/track/issues/24 >>>>>>>> >>>>>>>> Raised by: Tatsuya Igarashi >>>>>>>> On product: HOME_NETWORK_TF >>>>>>>> >>>>>>>> This is a proposal about the use case "Local Link of web >>>>> applications". >>>>>>>> >>>>>>>> See: http://www.w3.org/2011/webtv/track/issues/24 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> | Matt Hammond >>>>>> | Research Engineer, BBC R&D, Centre House, London >>>>>> | http://www.bbc.co.uk/rd/ >>>>>> >>>>> >>>> >>> >>> >>> -- >>> | Matt Hammond >>> | Research Engineer, BBC R&D, Centre House, London >>> | http://www.bbc.co.uk/rd/ >>> >>> >> > > -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/
Received on Tuesday, 21 June 2011 14:01:49 UTC