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

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

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Wed, 15 Jun 2011 10:33:05 +0200
To: public-web-and-tv@w3.org, "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>
Message-ID: <op.vw3zdfo86ugkrk@rabdomant-ubuntu>
On Tue, 14 Jun 2011 18:10:08 +0200, Jean-Claude Dufourd  
<jean-claude.dufourd@telecom-paristech.fr> wrote:

> 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.

This is my opinion as well.

But even if we design a generic API,
some scenarios may suggest extensions to existing technologies (<video>?)  
so I think it still make sense to have the list (as is in ISSUE-17) of  
more detailed use cases;
Furthermore, even though there are existing technologies covering the  
scenarios listed in ISSUE-17 (e.g. UPnP/DLNA),there could be complementary  
approaches/technologies that could be considered to cover some of these  
scenarios in different ecosystems.

So in short I personally think is good to keep ISSUE-17 as it is; no need  
to extend more. Is also good to mention existing HN protocols (UPnP,  
DNS-SD) but not to limit ourself to them.


> Best regards
> JC

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden
Received on Wednesday, 15 June 2011 08:33:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:05 UTC