W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2011

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

From: Clarke Stevens <C.Stevens@CableLabs.com>
Date: Wed, 15 Jun 2011 16:54:55 -0600
To: Russell Berkoff <r.berkoff@sisa.samsung.com>, Bob Lund <B.Lund@CableLabs.com>, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <3C0068AB22D70B4DA32B9A2A965968C773E6DF6FFA@srvxchg>
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] 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
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] 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

>
Received on Wednesday, 15 June 2011 22:55:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:03 UTC