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

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