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

Hello,
 
Please find responses. However, it appears we keep revisiting the same issues without making much forward progress,
 
Regards,
Russell Berkoff
Samsung
 
----------------------------------------
 
>>The choice of how much in JS and how much below the interface is an
implementation issue, provided the interface below the JS is private.


I disagree. This issue is relevant since the decision will influence the requirements the IG generates.
 
>>But somehow, I have difficulties seeing the fundamental difference
between "some basic network access methods provided by the UA" and
"resident parts of the UPnP stack".
It is possible to just implement all of the UPnP stack in JS on top of a
UDP socket interface, but that would have both security implications and
possibly performance too.

Many things are "possible"! Whether they are appropriate, correct, efficient are matters the IG needs to discuss when generating requirements. I can claim Canvas as a general solution to implement Codec support (since it can control screen pixels). However, clearly that would not be a reasonable approach.
What you are suggesting is equivalent to resetting the UPnP stack each time the UA loads a page.  This is inefficient since it would cause a rescan of UPnP devices each time a UA loads control point code. It is also broken subscriptions will be cancelled resulting in state variables will not be properly updated. 
This is not an acceptable design and it is not particularly relevant if you can get it to (sort-of) work in a particular implementation. Providing a basic media player implementation is not a proof of design/requirements correctness.
 
>>The choice of how much in JS and how much below the interface is an
implementation issue, provided the interface below the JS is private.

The claim of "implementation issues" seems to be somewhat arbitrary. I would suggest the IG take up the issue and clearly define what is considered an "implementation issue". 

>>  > 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.
>>JCD: That is what we are discussing already, if I am not mistaken.

Not all that clear. As stated some feel that providing basic network access in the UA would be a sufficient solution. I think there are issues that attach to this appropach which were enumerated previously.


________________________________

From: public-web-and-tv-request@w3.org on behalf of Jean-Claude Dufourd
Sent: Mon 6/20/2011 1:33 AM
To: Russell Berkoff
Cc: Giuseppe Pascale; Bob Lund; public-web-and-tv@w3.org
Subject: Re: about high-level or low-level API (ISSUE-17)



On 18/6/11 05:01 , Russell Berkoff wrote:
> 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.
JCD: We have implemented what you describe in our multimedia player
GPAC, using platinum for the UPnP support. So it is possible.
But somehow, I have difficulties seeing the fundamental difference
between "some basic network access methods provided by the UA" and
"resident parts of the UPnP stack".
It is possible to just implement all of the UPnP stack in JS on top of a
UDP socket interface, but that would have both security implications and
possibly performance too.
The choice of how much in JS and how much below the interface is an
implementation issue, provided the interface below the JS is private.

> 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.
JCD: That is what we are discussing already, if I am not mistaken.
Best regards
JC
> 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
>

--
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144