Re: [HOME_NETWORK_TF] Home Network Technologies

On Wed, 06 Apr 2011 12:37:55 +0200, Olivier Carmona <ocarmona@awox.com>  
wrote:
>
> 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.
>
Is out of question that reinventing the wheel is not what we want to do  
here.

If you look at the current requirement document draft[1], you can read the  
following design goal:
"Two home network protocols, UPnP and M-DNS/DNS-SD, are in popular use  
today for sharing content in a home network. This specification sets out  
the requirements for an API that would enable interaction with those  
protocols."

The aim of the Task Force is to identify gaps in the existing web  
technologies to cover some common Home Networking scenarios.

Of course one could argue that there are no such gaps and that all the  
technologies needed are our there;
If anybody has this point, feel free to expose it and argue for it.

If you believes there are gaps but they are different from the one so far  
discussed/identified,
once again feel free to point them out.

For your (and other new participants) members benefit, I would like to  
draw your attention on our requirement document draft [1].
Feel free to provide feedbacks directly on it.

Thanks for joining the TF discussion and providing your input.

[1] http://www.w3.org/2011/webtv/wiki/Home_Network_TF_Requirements

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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Wednesday, 6 April 2011 15:35:37 UTC