RE: [HOME_NETWORK_TF] Some comments on the open issues

Giuseppe,

I would certainly welcome the (chairs) proactively managing the agenda.

However, I have concerns about the TF not systematically covering issues raised on use cases. I don’t think open-calls for comments on submitted use cases during a teleconference is particularly effective given comments were previously submitted.

I would encourage the chairs to reconsider using "modern" collaboration tools which insure all participants are looking at the same content and allow comments to be captured and tracked within the documents.

Regards,
Russell Berkoff

-----Original Message-----
From: Giuseppe Pascale [mailto:giuseppep@opera.com] 
Sent: Friday, June 03, 2011 8:14 AM
To: Jean-Claude Dufourd; Russell Berkoff; Matt Hammond
Cc: public-web-and-tv@w3.org
Subject: [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)

@Russell,
did you had a look at JC rephrasing in the discussion page?
http://www.w3.org/2011/webtv/wiki/Talk:HNTF/Home_Network_TF_Discussions/UPnPHomeNetworkUA


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)


/g








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

Received on Sunday, 5 June 2011 12:24:56 UTC