RE: [HOME_NETWORK_TF] Home Network Technologies

Dear Matt,

Popping up in the discussion.

The attempt of creating a new home networking effort would not only be boiling the ocean again (your server / renderer approach below is rehash of DLNA 1.0, quite outdated indeed), but even more concerning, I do not see why you would leave aside an ecosystem of 440 million DLNA devices.

Although those devices may not fill all of your requirements, I do see an interest, as an end user, in relying on an ecosystem to instantiate scenarios, as you said "we don't have to enable all capabilities first time round".

To answer Giuseppe, seeing wider than UPnP, well, I can only think of:

-  Bonjour, and AirPlay of course. However, AirPlay is not an open standard as far as I know.

- SAMBA / NFS, not sure although that those solutions are attractive.

Thanks for your attention.

With my best regards,
Olivier Carmona

-----Original Message-----
From: Matt Hammond [mailto:matt.hammond@rd.bbc.co.uk]
Sent: mercredi 6 avril 2011 12:10
To: public-web-and-tv@w3.org; Russell Berkoff; Giuseppe Pascale
Subject: 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/




__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6018 (20110406) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com




__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 6018 (20110406) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

Received on Thursday, 7 April 2011 01:28:29 UTC