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

From: Russell Berkoff [mailto:r.berkoff@sisa.samsung.com]
Sent: Wednesday, June 15, 2011 4:33 PM
To: Bob Lund; Jean-Claude Dufourd; 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. [A discovery API that is mapped to the established home networking protocols understood by the user agent. Which established home networking protocol to invoke could be a parameter in the API].

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? [The idea behind a low-level API is that it is independent of the existing home network standards. All home networking standards supported by the UA are exposed via a common API. How a UA provides support for a particular set of home networking standards occurs is an UA implementation decision]

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. [I think you agreed in the last call that this is a question of how Web content in a UA provides a content-based home networking service. Service discovery and access happens the same whether the service is UA based or some other implementation]

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. [This is an important question that must be addressed whether the API is high level or low 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.



Regards,

Russell Berkoff

Samsung





-----Original Message-----
From: 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
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] On Behalf Of Jean-Claude Dufourd

> Sent: Tuesday, June 14, 2011 10:10 AM

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

>