Re: [HOME_NETWORK_TF] Some comments on the open issues

On 06/03/2011 05:14 PM, Giuseppe Pascale wrote:
> ** 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.

Details in ISSUE-7 may help emphasise that:
  1/ some vocabulary is needed to describe existing service connections as part of an execution context
  2/ user permissions can be part of the execution context (re-connection between the device that acts as remote control and the migrated service does not require another user validation). This could help discover security holes, as the weakest HNTF UA in a network of HNTF UA that support migration could potentially become a risk for the whole local network: once a device manages to hack a connection with the weakest HNTF UA in a network, it can then migrate this connection to other HNTF UAs without the user's explicit consent. That probably isn't such a big deal though as the user remains the one who initiates the migration, normally.

So it may be useful to keep both use cases separated, although we probably do not need such a detailed use case here.
(the description of the radio service could perhaps be re-used in other more generic use cases actually, it's clear and visual!)

Francois.


[...]
>
> ** Application Exposing a Service (ISSUE-12)
> 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.

Received on Monday, 6 June 2011 12:35:45 UTC