Re: [HOME_NETWORK_TF] Home Network Technologies

On Mon, 04 Apr 2011 10:43:12 +0100, Giuseppe Pascale <giuseppep@opera.com>  
wrote:

> I agree. My point was that the analysis should start looking at a wider  
> scope than just UPnP,
> looking if some convergence is possible and at which level. One possible  
> outcome could be that this convergence is possible just in same areas or  
> is not possible at all.
>
> I would encourage TF participants to share their opinion on this point.

+1. I believe UPnP, specifically in its most commonly deployed form, DLNA,  
supports some usage scenarios (such as streaming between devices) well,  
and others (such as accessing broadcast and on-demand TV services) less  
well.

>> UPnP (for example) has built-up device models for various HN things  
>> like DVRs, EPG and Media Servers and Media Renderers over the last 10+  
>> years. Is there a suggestion that DAP is going to try to "boil the  
>> ocean" on this?

Some of this complexity could be due to the model adopted and the problems  
it tries to solve - not only that of control but also the streaming of  
content. It therefore has to concern itself with codecs, formats,  
streaming protocols, resolutions etc.

If we decide to concentrate on the command and control aspects, then I  
believe there are models in which clients need not concern themselves with  
many of these issues. Separately the device being controlled can be using  
UPnP and other protocols to enact what it is requested to do.

Our UC API work at the BBC attempts to do this: we simplify the model down  
to a rendering device (the server) and client. The client can ask the  
server what content it can play and can request one of those items be  
played. It is left up to the server to determine where and how it can  
obtain content (eg. via UPnP, broadcast, local storage etc).

In this context, yes a rendering device would need to potentially  
implement a new API. But the client becomes significantly simplified and  
classes/types/profiles of media device matter much less. The ocean is  
substantially smaller :)

> Another point for discussion would then be if we should focus on few  
> services that are considered of higher priority (e.g. Media  
> Server/Renderer) and consider other types of services later,
> rather then trying to define a generic model that can cover all possible  
> services.

+1. We don't have to enable all capabilities first time round.


Matt
-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

Received on Wednesday, 6 April 2011 10:10:52 UTC