- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Wed, 13 Apr 2011 09:54:23 +0200
- To: Bob Lund <B.Lund@CableLabs.com>
- CC: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
On 12/4/11 16:51 , Bob Lund wrote: > >> -----Original Message----- >> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv- >> request@w3.org] On Behalf Of Jean-Claude Dufourd >> Sent: Tuesday, April 12, 2011 6:12 AM >> To: public-web-and-tv@w3.org >> Subject: Re: [HOME_NETWORK_TF] Some use cases and requirements for >> broadcast TV applications >> >> On 11/4/11 21:52 , Bob Lund wrote: >>> UC4 seems like a web server function: UI from server X moves from >> client A to client B. This could be done by a web server with HTML5 >> within a home network or across the internet. Nothing new is required, I >> think. UC5 has the element of device A discovering a service on device B >> and device A creating UI presented on device B. >>> Bob >> JCD: UC4 is about moving the interface (HTML page plus all its >> ressources) *plus* the current state of the interface, such as which >> choices are already made. >> So the question is, where does the state reside. >> >> Option 1: You have an intelligent server on the Internet, and the web >> page on the terminal is progressively updated using AJAX. The state >> information is on the server, and the terminal is just a mirror of this >> information. It is feasible indeed to connect from another terminal, >> identify as the same user, and get the intelligent server to switch to >> using the new terminal for the already started session. >> >> Option 2: The intelligence is in the web page (widget-style). The server >> is plain HTTP. The state information is in the page. The you have no way >> to transfer the state information. You can restart the interface >> elsewhere, but it starts "at the beginning". >> >> >> I claim that option 2 is useful and needed, for example to satisfy >> privacy concerns, hence my proposal for UC4. >> Best regards >> JC > I agree these are the options. I think option 1 can be implemented exclusively through JavaScript so would lend itself to deployment to any existing browser. For option 2, are you proposing a HN service on the target client that the source client invokes and transfers its UI state to? If so, I would agree this fits within the HNTF scope. JCD: Yes, I am proposing a mechanism to transfer UI state. You sketch a push mechanism, whereas we have currently implemented a pull mechanism. The sender advertizes the URL of the UI state, and the receiver pulls the UI state off the URL. Actually, the full implemented mechanism is: 1- all possible target client advertizes themselves as providers of a service called "home network user agent" 2- the source client discovers the target client 3- the source client binds to the target client then sends a message with the URL of the content and the URL of the UI state 4- the target client fetches the UI content then the UI state Because we are using UPnP, this pull solution is easier. Best regards JC > Regards, > Bob >> -- >> >> JC Dufourd >> Directeur d'Etudes/Professor >> Groupe Multimedia/Multimedia Group >> Traitement du Signal et Images/Signal and Image Processing Telecom >> ParisTech, 37-39 rue Dareau, 75014 Paris, France >> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144 >> -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Wednesday, 13 April 2011 07:54:49 UTC