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 Tuesday, 14 June 2011 16:54:20 UTC