Re: [HOME_NETWORK_TF] Some use cases and requirements for broadcast TV applications

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