[HOME_NETWORK_TF] What to do with webtv-issue-20

Hi,

At the last conf call I attended (22nd June) it was suggested that I  
should look at how issue-20 (TV Control) [1] be best combined with issue-4  
(Service UI) [2].

Having spent some time considering this, I am not sure I understand the  
rationale presented for suggesting the best fit be issue-4. The intended  
purpose of the "TV Control" use case is to highlight a particular class of  
application that it should be possible to implement. Issue-28 (Home  
Network UA Media Controller) [3], for example, seems to aim to achieve a  
similar goal for applications that initiate and control the streaming of  
media from one device to another device for rendering.

The difference is in the degree of support for these scenarios in common  
deployments of existing underlying protocols (such as UPnP). For proposed  
use cases such as issue-28 there is unquestionably existing protocol  
support widely deployed. By contrast, as explained earlier emails, this  
seems less certain for "TV Control". The device that is rendering/playing  
the media content may also be directly receiving it (such as from live  
broadcast transmissions) and may be incapable of streaming that content  
from/to other devices. The two are, from a media streaming/transfer  
perspective, inseparable.

In earlier discussions, various other TF participants have indicated at  
least some degree of support for these scenarios through UPnP services [4]  
e.g. content directory services listing broadcast tuner programmes, and  
control of media rendering attributes such as volume. Even if some aspects  
are not supported now, of course, UPnP, or other future protocols, could  
be extended or devices to fill these gaps.

There seems to be consensus that this TF will almost certainly recommend  
generic discovery APIs and some form of generic access APIs for underlying  
protocols (such as UPnP). It is less certain whether there may also be  
recommendations to create slightly higher level APIs to abstract functions  
for media streaming, playback etc - as listed in issues 26, 27, 28, 29 and  
30. My understanding is that this is an open possibility.

Do we consider it worth capturing use cases that describe the types of  
tasks that need to be supportable in such a higher level API? If we do  
then the "TV Control" should be retained as an independent issue. If, for  
example, such an API leans on a 3-box model architecture, it should be  
able to support scenarios where 2 of those boxes (server and renderer) may  
be inseparable as described. I can rework the use-case to focus on a  
likely chain of events/method invocations, more closely matching the other  
issues, such as 26-30.

If the TF considers recommendations regarding higher level APIs outside of  
its remit, then the "TV  Control" use case would seem to be out of scope  
of this TF's work, and I would therefore withdraw it.

regards



Matt

[1]  
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TVControl

[2]  
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/ServiceUI

[3]  
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/HomeNetworkUA_MediaController

[4] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Apr/0036.html
     http://lists.w3.org/Archives/Public/public-web-and-tv/2011Apr/0068.html
-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

Received on Sunday, 3 July 2011 21:56:46 UTC