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
> 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

Received on Monday, 20 June 2011 08:34:27 UTC