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

On Tue, 14 Jun 2011 18:10:08 +0200, Jean-Claude Dufourd  
<> 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