- From: Matt Hammond <matt.hammond@rd.bbc.co.uk>
- Date: Tue, 21 Jun 2011 09:37:38 +0100
- To: "Giuseppe Pascale" <giuseppep@opera.com>, "Bob Lund" <B.Lund@cablelabs.com>, "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>, public-web-and-tv@w3.org, "Russell Berkoff" <r.berkoff@sisa.samsung.com>
Hi, a question and comment or two inline... regards Matt On Sat, 18 Jun 2011 04:01:02 +0100, Russell Berkoff <r.berkoff@sisa.samsung.com> wrote: > Hello, > > Sorry, maybe I'm just "slow on the uptake" here? > > A suggestion has been made to bundle HN stacks in page-code that is > downloaded into the UA which uses some basic network access methods > provided by the UA. > > The approach suggested seems unworkable since UPnP stacks need to > monitor the network consistently not just when page-code containing the > stack is running in the UA. Failure to do this will cause UPnP to break > in the areas of device detection (missing devices entering and leaving > the network), state variable maintenance (loss of updates to network > variables), and event management (loss of device events). These > functions are generally done in resident parts of the UPnP stack which > are expected to be operating continuously. Then page-code can "ask" the > UPnP stack what happened when the upper layers of the UPnP client are > not operating. Does this concern apply to controllers (the right UPnP terminology I hope) running in the UA, as well as servers, renderers etc? To me this indicates that a desireable characteristic of any API provided by the UA for apps is that it tries to minimise statefulness. > If browser vendors need to implement built-in UPnP support what API do > they proffer to page-code? My expectation is that the HNTF would > describe this IDL so browser vendors would not need to implement > n-different stack interfaces. > > I have additional concerns if UA's implement server functions, that the > UA single-threaded event model may be insufficient to support the server. Is this an issue of concurrency or multi-threading? Javascript APIs can be designed to be asynchronous and therefore amenable to creating concurrent code. > This is not a run-walk-crawl issue. This is a matter of providing > adequate platform enabling to efficiently implement HN access protocols. > One-size does not fit all in this case. > > Regards, > Russell Berkoff > Samsung > > > -----Original Message----- > From: Giuseppe Pascale [mailto:giuseppep@opera.com] > Sent: Friday, June 17, 2011 6:12 AM > To: Bob Lund; Jean-Claude Dufourd; public-web-and-tv@w3.org; Russell > Berkoff > Subject: Re: about high-level or low-level API (ISSUE-17) > > On Thu, 16 Jun 2011 00:32:45 +0200, Russell Berkoff > <r.berkoff@sisa.samsung.com> wrote: >> 1. How does a "generic" discovery framework address the needs of >> existing ecosystems with existing and well established discovery and >> network protocols. >> > > Isn't this problem similar to video (codec) and image format support in > different browsers? > I don't think is technically an issue. Of course there are some > challenges, and we will have to discuss them once we move into the > technical discussion. > More the technical challenges, I expect we will have to discuss > thread-off between what should be exposed to the application and what > should be not exposed. > > Furthermore industry groups may define profiles where they mandate > support for one (or more) networking protocols even though we design an > agnostic API. > >> 2. How does a UA support one (or more) of the existing HomeNetwork >> standards? I thought (an) objective of HTML5 was to eliminate the need >> for browser-specific plug-in modules? >> > The idea is not plugins but just platform support for a specific > protocol. > Once again, I think the example of codecs for <video> is similar to what > we are discussing here. > > >> 3. How does a UA (in particular one that provides Device/File >> services) connect to platform devices and files? I suspect that the >> demands for metadata storage alone would greatly exceed what is >> anticipated in WebStorage. >> > I don't think WebStorage is the way to go for this kind of scenario. > Rather you could use some File API to access the file system, something > like this http://dev.opera.com/articles/view/file-i-o-api-for-widgets/ > http://www.w3.org/TR/FileAPI/ > > >> 4. How would generic UA network access services to do discovery and >> commanding be secure? In theory any webpage/plugin code could "hijack" >> a UA causing security and privacy issues. >> > To (try to) solve this we need IMO minimize the information exposed to > the application and leave some control to the browser. > I think discovery should be completely under the UA control, and also > the information exposed should be filtered based on some security policy > with the possibility for the UA to implement even stricter security > policies if needed. Pairing will be probably needed before 2 devices can > communicate (CORS[1] could alternatively be used to introduce some > "automation"). This is an important topic, so needs for sure more > thought, but I thin'k there is room for something that enables the most > important usecases. > > > [1] http://www.w3.org/TR/cors/ > > /g > > -- > Giuseppe Pascale > TV & Connected Devices > Opera Software - Sweden -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/
Received on Tuesday, 21 June 2011 08:38:41 UTC