Re: webtv-Issue-20: TV Querying and Control

Hi,

Please see comments inline below.

regards


Matt

On Mon, 06 Jun 2011 09:17:27 +0100, Russell Berkoff  
<r.berkoff@sisa.samsung.com> wrote:

> Hello,
>
>
> The submitter's test case appears redundant with long standing UPnP
> function. We agreed to convey these requirements in a generic way as
> part of  Issue-17 as well as in a UPnP specific way as discussed on the
> previous call.
>
>
> The Justification section appears to incorrectly characterize UPnP:
>
>
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TVCon
> trol
>
>
> I've repeated the Justification  section since the W3 tools do not allow
> comments to be attached to submitted document.
>
>
> Justification:
>
> * Allows the creation of user interfaces utilizing companion
> device features, such as touch screens. Such interfaces may have greater
> usability than can be achieved with a traditional infra-red button based
> remote control and on-television interface.
>
> UPnP allows any device to act as an external control point. This device
> can determine the current state of the rendering device as well as
> control the device.
>
> * Standardisation could facilitate a new ecosystem of interfaces.
> * Existing standards for home network communication are not
> available from the browser context
>
> Actually CEA-2014-B has a web-binding for UPnP devices. PHP has a
> binding for UPnP Devices (GUPnP). A desirable goal of this TF is to have
> W3C also publish these (or similar bindings).

The intention with this statement was to point to the current lack of  
ability to access technologies (such as UPnP) *directly* from within, for  
example, a browser running on an iPad, android device, or laptop. I  
believe the interests of many in this TF is to plug precisely this gap for  
the likes of UPnP. Could an alternative wording capture this more  
precisely?

> * Existing standards (UPnP?) do not support query and control of
> content playback where the content is not being streamed between devices
>
>
> UPnP embodies no such restriction. There is nothing in UPnP that
> precludes a MediaRenderer from publishing locally based changes of
> device state. If anything this would be encouraged to provide a
> consistent user experience.

I am very happy to see these use cases folded into issue-17, so long as  
the specific requirement that these functions be possible in the context  
of receiving broadcast content, and not just for the context of streaming  
between devices in the home.

 From my perspective, the set of possible capabilities in the collection of  
specifications constituting UPnP seems considerably larger than what, in  
practice, appears to be implemented. The functions that seem to be  
implemented in actual devices concern with the use cases for streaming  
media content - an excellent success largely attributable to the DLNA  
initiative.

Could the issue I am trying to raise be captured to everyone's  
satisfaction by rephrasing to say: "They ways in which existing standards  
are currently deployed in home devices do not support ..." ?



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

Received on Monday, 6 June 2011 09:15:35 UTC