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

On Tue, 21 Jun 2011 10:26:10 +0200, Russell Berkoff  
<r.berkoff@sisa.samsung.com> wrote:

> What you are suggesting is equivalent to resetting the UPnP stack each  
> time the UA loads a page.

This is not what we are suggesting (or at least some of us are suggesting).
The UA will have full control of the discover process and expose (with the  
due security mechanisms) information to an application when the app  
request it.
So it will always be running as far as the UA is running (or even if the  
UA is not running, that would be an implementation choice)

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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 21 June 2011 09:17:03 UTC