RE: [HOME_NETWORK_TF] Some comments on the open issues

That sounds good and is probably the only practical way to stay on schedule.


> -----Original Message-----
> From: [mailto:public-web-and-tv-
>] On Behalf Of Giuseppe Pascale
> Sent: Friday, June 03, 2011 9:14 AM
> To: Jean-Claude Dufourd; Russell Berkoff; Matt Hammond
> Cc:
> 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?

> sions/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 Friday, 3 June 2011 15:58:44 UTC