- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Tue, 07 Jun 2011 13:20:46 +0200
- To: "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>, "Matt Hammond" <matt.hammond@rd.bbc.co.uk>, "Russell Berkoff" <r.berkoff@sisa.samsung.com>
- Cc: public-web-and-tv@w3.org
On Sun, 05 Jun 2011 14:24:26 +0200, Russell Berkoff <r.berkoff@sisa.samsung.com> wrote: > Giuseppe, > Russell, > 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. > In fact comments would be better submitted over email. I think most of the W3C groups work this way; Maybe other people on this list working with other WGs can share their experience > 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. > If you have a concrete proposal for better procedures and tools feel free to make it and this group (all of us) will evaluate it. From a W3C PoV, any tool that does not require some sort of fee and work across systems should be fine. /g > 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 -- Giuseppe Pascale TV & Connected Devices Opera Software - Sweden
Received on Tuesday, 7 June 2011 11:21:26 UTC