[HOME_NETWORK_TF] Some comments on the open issues

Hi all,
here my comments on some of the open issues, feedbacks (from everybody)  
are welcome.

Note that to avoid to only touch on 1/2 use cases in each telco, I would  
like during next telcos not to spend more than 10/15 minutes per usecase.
This means we will have to do the rest of the discussion over email, and  
hopefully use telcos for final discussion and approval.
What do you think about this approach? please let me know, I'm open for  
any suggestion that allow us to get more work done.

** Service User Interface (ISSUE-4)
As we have discussed few times, this could overlap with ISSUE-17 (UPnP) if  
that use cases is rephrased, but it could also be a superset of it.
We can either approve it as is and later decide to drop it if the outcome  
of ISSUE-17 is generic enough to cover this or we can wait with this until  
ISSUE-17 is solved.

@JC, Russel, any opinion on this?

**  Service Migration (ISSUE-7)
I think this use case is valid, but there seems to be still a lot of  
confusion around it.
Can people point out what is missing and how can it be clarified?

Maybe one way could be to point out explicitly that there are 2 way to  
implement this use cases
- with a central server (in the home) where to store the state of the  
Service to be able to resume it later on--> this can be done already, so  
out of scope
- without a central server (e.g. a Widget),so you need to migrate both the  
"content" /hmlt/js/images) and the state from one device to another. This  
is in scope.

On the other end, I'm also wondering it we really need this use case, or  
if this is already implied by having Application Migration + Application  
Exposing a service.
Does an application exposing a service that migrates add more requirements  
compared to a "simple" application that migrates? Note that the an  
application that migrates still have a state to preserve, and since we  
don't define what "state" is, it could also be the state of the service.

** Service Distribution (ISSUE-8)
This looks fine to me, even though as you say the only additional  
requirement of the use case (compared to the others) is to be able to push  
services rather then discover services.
Probably good to extend with few more words the "Need/justification:"  
section of the template

** Application Exposing a Service (ISSUE-12)
Looks fine to me

** Application Responding to Requests (ISSUE-13)
Is this really needed as a separate use case? Isn't this part of the  
"expose a service" and "discover a service" usecase?

** Application Discovering a Service (ISSUE-14)
Looks fine to me

** Application Migration (ISSUE-15)
Also for this maybe is worth mentioning that there are 2 ways to support  
this Usecase,
- central server (e.g. your TV) so that you can "log out" from one device  
and "log in" in another device and keep the state; this doesn't seem to  
require any additional technology so is not in the scope.
- the application is a local application (e.g. widget) so you need to move  
both the application and the state.

Maybe you could even rewrite this use case to explicitly and solely  
mention the "local" applications, since for application served by a HN web  
server there is no need for a migration functionality.

** Media identification (ISSUE-19)
I agree that the use cases is a valid one but I have few question:
- isn't this already implicitly included in the use cases listed above?
- is the use cases only about being able to query a unique identifier for  
content/programs or also about standardize this identifier?

** TV Querying and Control (ISSUE-20)
This seems to be the same as Issue-4, even though issue-4 is probably too  
generic while this give one particular example of control. I'm not sure  
how we should handle these usecases, if we should keep both, only the  
generic one or only the specific ones. IMO we should keep both

** Time Synchronisation (ISSUE-21)
Looks fine to me. Same comment as above apply (generic vs specific)

** Lip-Sync accuracy Time Synchronisation (ISSUE-22)
Looks fine to me. Same comment as above apply (generic vs specific)

** UPnP / DLNA Home Network Enabled User-Agent (ISSUE-17)

did you had a look at JC rephrasing in the discussion page?

Is probably a good starting point.

I don't have a strong opinion about keeping everything in one use cases vs  
splitting them up. I would prefer to have at list a split between "The  
User-Agent commands other home network devices" and "The User-Agent acts  
as a HomeNetwork device.", but no need to go more fine grain than this.

Note also that some of the usecases described overlap with some of JC's  
ones (e.g. Device Discovery), so if we approve this we can probably drop  
the others (or vice versa)


Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Friday, 3 June 2011 15:19:30 UTC