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

On Fri, 17 Jun 2011 04:10:25 +0200, Gadiraju, Narm <narm@intel.com> wrote:

> Agree with Mark on the Crawl-Walk-Run approach as this will help us  
> enable basic mechanisms first and iron out all potential implementation  
> issues.
>

On this point let me clarify that (as mentioned in the charter) there is  
no need to stop our discussion in July if there are still open topics.
We could "freeze" a first set of requirements (the low level API?) so that  
this could be addressed by a working group and discussed in more technical  
details (level that we don't usually touch)
and the HNTF could continue to work on a second requirement document for  
future phases.

/g



> - narm
>
> narm gadiraju
> narm@intel.com<mailto:narm@intel.com> | W: 503-712-8599 | M: 503-705-0573
>
>
> From: public-web-and-tv-request@w3.org  
> [mailto:public-web-and-tv-request@w3..org] On Behalf Of Vickers, Mark
> Sent: Wednesday, June 15, 2011 5:15 PM
> To: Clarke Stevens
> Cc: Russell Berkoff; Bob Lund; Jean-Claude Dufourd;  
> public-web-and-tv@w3.org
> Subject: Re: about high-level or low-level API (ISSUE-17)
>
> I think this is a crawl-walk-run situation.
>
> Currently, browsers are at the standing still phase of home networking  
> because they can't even discover or connect to a home network device or  
> service..
>
> An initial crawl phase:
> - discovery and generic messaging
> - requires key security and privacy issues be addressed. I think  
> user-permission will be required.
> - should work for any protocol family: UPnP, ZeroConf, SLP, etc.
> - higher-level, ecosystem support (UpNp/DLNA, BonJour) could be built in  
> JS applications or in JS libraries
>
> Following walk-run phases:
> - Probably several service-specific requirement/API efforts, different  
> difficulty, different expert groups
> - May need to address service APIs that work on both LAN & WAN
>
> Just developing secure, privacy-protecting, generic discovery and  
> messaging requirements and APIs for the crawl phase will be a major  
> accomplishment.
>
> Thanks,
> mav
>
> On Jun 15, 2011, at 3:54 PM, Clarke Stevens wrote:
>
>
> Russell,
>
> Let me address your points below. I've done some prototyping on this, so  
> I have a pretty good idea of at least one way to do it.
>
> -Clarke
>
> From:  
> public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>  
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Russell Berkoff
> Sent: Wednesday, June 15, 2011 4:33 PM
> To: Bob Lund; Jean-Claude Dufourd;  
> public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
> Subject: RE: about high-level or low-level API (ISSUE-17)
>
> Hello,
>
> I'm guess I'm confused on a number of accounts:
>
> 1.  How does a "generic" discovery framework address the needs of  
> existing ecosystems with existing and well established discovery and  
> network protocols.
>>> The "browser" (integrated, plug-in, applet, etc.) can send and receive  
>>> messages that are reduced to strings. The logic of how these messages  
>>> are handled can be done at the JavaScript layer. In our experiments we  
>>> can do this with APIs that work for both UPnP and ZeroConf (Bonjour).
> 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?
>>> It's impossible to implement a specific protocol without defining that  
>>> protocol on some level. One way to do this is to have a generic class  
>>> that implements a generic interface and derive protocol specific  
>>> subclasses from that to do the actual implementations.
> 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.
>>> You don't need to read everything at once. You can limit (e.g. through  
>>> a hierarchical interface or limiting the number of displayed items)  
>>> the user interface to something that is manageable in the available  
>>> memory space.
> 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.
>>> Security is relative. Having said that, an authenticated application  
>>> from a trusted source using the security features of the specific  
>>> protocol or link-level security are tools we can use to increase the  
>>> relative security level.
>
> I think it would be helpful if the IG focused more on deriving  
> real-world requirements. If anything the discussion seems to indicate  
> that the high-level requirements in ISSUE-17 may result in additional  
> requirements on the UA platform to provide the necessary support for  
> HNTF access methods for currently deployed HNTF network technologies. I  
> would suggest the IG address these items.
>
>>> I strongly agree that we need to work with existing protocols and the  
>>> accomplishment of this objective is a key measure of the success of  
>>> HNTF. Fortunately, the low-level solution does not preclude the  
>>> high-level solution. Specification of the high-level solution brings  
>>> additional challenges in abstracting protocols with different  
>>> approaches and assumptions. I think this is something that we need to  
>>> consider, but I think the group can provide the simpler and more  
>>> general solution in the meantime.
>
> Regards,
> Russell Berkoff
> Samsung
>
>
> -----Original Message-----
> From:  
> public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>  
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Bob Lund
> Sent: Tuesday, June 14, 2011 9:54 AM
> To: Jean-Claude Dufourd;  
> public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
> Subject: RE: about high-level or low-level API (ISSUE-17)
>
>
>
>> -----Original Message-----
>> From:  
>> public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>  
>> [mailto:public-web-and-tv-
>> request@w3.org] On Behalf Of Jean-Claude Dufourd
>> Sent: Tuesday, June 14, 2011 10:10 AM
>> To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
>> Subject: about high-level or low-level API (ISSUE-17)
>>
>> Dear all,
>>
>> I want to ask my question again in writing, because I did not get an
>> answer during the call and yet I think we need to answer it in order
>> to know what to do with ISSUE-17.
>> What is the intent of ISSUE-17 ?
>> Is it to standardize a list of API calls, the first of which (in the
>> text) being "list discoverable home network media servers" ?
>> Or is it to standardize a generic messaging API, and check that
>> everything listed in ISSUE-17 is possible ?
>> This actually applies to more than just ISSUE-17
>>
>> If it is the first, then it is meaningful to discuss ISSUE-17 in
>> detail, bullet by bullet. So we would need a lot of telco time.
>> If it is the second, then I believe it is not meaningful to discuss
>> ISSUE-17 bullet by bullet, but just keep the list for later validation
>> of the standard. If so we should not have spent as much time on it in
>> today's telco.
>>
>> Then my opinion on this subject is that we should only standardize a
>> small, low-level API for generic messaging, and not a very large set
>> of high-level messages that would never be up-to-date in the rapidly
>> evolving ecosystem of the home network.
>> We should definitely design a standard that allows a document to call
>> any of the UPnP/DLNA services mentioned in ISSUE-17, but does not
>> duplicate the UPnP/DLNA service interfaces.
>
> I agree with this. In addition to the issue of staying up to date, some  
> home networking technologies do not standardize the semantics of a  
> particular service interface, DNS-SD for example. There is a general  
> discovery mechanism and a generic syntax for exchanging messages but the  
> contents of the message are specific to the service. Exposing a service  
> specific API in the user agent then implies the user agent has service  
> specific knowledge. Clearly this does not scale.
>
> I think the best course of action is to start with a generic API that  
> focuses on service discovery and a generic message passing and event  
> mechanism. As the industry gets experience with this, it may become that  
> higher level APIs would be appropriate. JavaScript functions could be  
> defined to provide a home network technology specific interface if that  
> is felt to be valuable.
>
> Bob
>> Best regards
>> JC
>>
>> --
>> 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 Friday, 17 June 2011 12:35:24 UTC