Re: [HOME_NETWORK_TF] Some use cases and requirements for broadcast TV applications (ISSUE-7)

** added ISSUE-7 to the subject for tracking purposes ***


On Wed, 13 Apr 2011 09:54:23 +0200, Jean-Claude Dufourd  
<jean-claude.dufourd@telecom-paristech.fr> wrote:

> 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".
>>>
This could actually be an interesting requirement to contribute to the WG  
working on Widgets,
i.e. being able to "move" a widgets among devices (including the state of  
the widget)


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

Agree, so this option can be ignored for our purpose.

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

Some comment on the current text:
** maybe would be better to change "document" with something more generic
In general I see 2 things we want to be able to move: services and content.
The "document" case is probably a but ambiguous since it could be regarded  
both as a service and as content.
In your case would be probably better to use service though, so saying  
somethin like "A service moving across devices", "how do we move a service  
and its current "state" to another device" etc.

So a document would be a specific case for a more general case of service  
migration. This also imply that you need a mechanism for devices to  
negotiate a supported "service" type
What do you think?

@Bob,
Would this address also your comment?

Note that this would require a clear definition of "service" that should  
include things like, for example, a Remote UI.

** please try to fill in the "Need/justification" section, that really  
important to progress the discussion and have final approval of the use  
case.

/g


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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 26 April 2011 13:05:32 UTC