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.

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? 

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.

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.

 

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

>