- From: Nord, Christian <Christian.Nord@sonyericsson.com>
- Date: Tue, 7 Jun 2011 15:56:37 +0200
- To: Scott Wilson <scott.bradley.wilson@gmail.com>, Matt Hammond <matt.hammond@rd.bbc.co.uk>
- CC: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
I'd second that the "web" part is important. I fully understand that we are the Home Network TF but I think there is benefit in looking at how we could apply more of the "web" view on this, in that when you interact with several devices they may not always be on your local/home network. I would be looking for a mechanism that would allow web applications to discover the devices that are most relevant to you at any given moment. At least as a placeholder in the framework that would allow services to provide this discovery mechanism. Or would this be covered by existing technologies? Kind regards, Christian On 7 jun 2011, at 10:56, Scott Wilson wrote: > I think its important not to lose sight of the "web" part. What I'm interested in is web applications/W3C widgets being able to interact with the capabilities of the TV and the content. This means that, while UPnP is quite possibly the underlying implementation, there is still a need to expose the capabilities in a way that makes sense for web developers implementing applications in HTML5 and JavaScript rather than low-level native applications directly accessing the hardware layer, which is already possible. > > PS I would take a look at the CEA web binding, but like most web developers I won't spend $450 on a spec document :) > > On 7 Jun 2011, at 09:34, Matt Hammond wrote: > >> Hi, >> >> Jean-Claude - thanks for your question - I think its a pertinent one. I'll try to explain my perspective and motivations in more detail: >> >> Our interest in the web and TV interest group is as a content and service creator wishing to be able to content and services that bring web and TV together. In particular, as we presented at the last IG workshop, from a starting point of dual-screen styles of application. Therefore we have submitted use cases (scenarios?) with the intent of suggesting what content and services should be enabled. >> >> Yes - from that perspective, we would hope to be able to create content that can communicate with TVs and other devices across a range of platforms and manufacturers. This is extremely important to us. As a content creator, costs of production can quickly become prohibitive if we have to substantially repurpose content for every platform and device we wish to serve on. >> >> When envisaging the creation this kind of content/services: access to UPnP services does not feel ideal (without substantial abstraction) since we perceive them to be lower level and more complex than, for example, a web api of the form that we experimented with, and which we have publicly shared. >> >> However I acknowledge the substantial existing support for UPnP. I can also see that parts of UPnP do cover these scenarios in some cases. It has been helpful to find out from other TF participants precisely what can be done with UPnP - it has been not at all obvious to me whether some of our scenarios could be supported for the case of a single device receiving live broadcast content (eg. TV with integrated tuner) - especially as it seems that deployments of UPnP standards focus on the streaming of media between devices. >> >> I have tried to recast our contributions in a relatively technology agnostic form, and am happy to continue to refine them when overlaps with suitable existing technologies are identified. >> >> >> regards >> >> >> >> Matt >> >> On Mon, 06 Jun 2011 18:47:25 +0100, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr> wrote: >> >>> I agree with Russell's points. >>> The use case can be implemented today with UPnP, yes, I have done pieces >>> of that, and I believe Matt's team did more. >>> But I wonder about Matt's intent. >>> Is the intent of the use case that the HNTF-chartered WG would define a >>> standard interface to those TV services, so that any companion device >>> can connect to it without knowing the make of the TV ? In other words, >>> that WG would define an abstract service to change the volume, change >>> the channel, etc... in a way that can be mapped onto UPnP services. >>> If so, I do not know if I support it. >>> Best regards >>> JC >>> >>> On 6/6/11 10:17 , Russell Berkoff 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/TVControl >>>> >>>> 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). >>>> >>>> * 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. >>>> >>>> Regards, >>>> >>>> Russell Berkoff >>>> >>>> Samsung >>>> >>> >>> >> >> >> -- >> | Matt Hammond >> | Research Engineer, BBC R&D, Centre House, London >> | http://www.bbc.co.uk/rd/ >> > >
Received on Tuesday, 7 June 2011 13:57:18 UTC