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

On 21/6/11 10:26 , Russell Berkoff wrote:
> >>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.
JCD: I do not see how, but as you are saying, we are discussing in 
circles here, emailing will not solve it.

> >>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.
JCD: That is incorrect. As I said we have implemented what I wrote and 
there is no such resetting of the UPnP stack.
Since all your later arguments hinge on this claim about the reset, 
you'll understand that I do not even discuss them.
>  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".
JCD: I repeat: I participated in the implementation of a UPnP extension 
in a browser. What I write is informed by this implementation and 
specific discussions about how much to implement in JS and how much in C 
code. 80% of our implementation is in JS, and of the 20% of C, most of 
it is to hide private structures to implement security limitations. 
Note: the platinum code is not included in the code size estimation.
It was our choice. The implementation is still conformant to ISO/IEC 
23007-1 MPEG-U Widgets. That is exactly what I define as an 
implementation issue: a choice by the implementer that does not impact 
the conformity of the result to a standard.
Regards
JC
>
> >> > 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
>
>


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