RE: about high-level or low-level API (ISSUE-17)

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.

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.

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

Received on Saturday, 18 June 2011 03:01:33 UTC