Re: DAP rechartering discussion

Hi Mark, thanks for your comments.

Our original motivation for developing this kind of API was to improve  
device accessibility, by enabling third parties to create novel and/or  
custom remote controls meeting particular users' needs. To this end, the  
API in our spec aims to support a core of common functionality.

As I think you have identified, effectively requires (and this API  
enables) a decoupling of the remote control from the service. But that  
would not stop more tightly coupled pairings from still being created.

Hopefully in this context, some of my answers below will make more sense.  
I've snipped some of the thread history for brevity.

On Wed, 16 Mar 2011 04:32:34 -0000, Mark Watson <watsonm@netflix.com>  
wrote:

> Hi Matt,
>
> Thanks for the explanation.
>
> My main comment is that I would not expect standardization to reach so  
> high in the stack. Or at least we should decouple the discovery,  
> connectivity and security aspects (which are generically useful) from  
> aspects such as content search and metadata, which IMO are  
> service-specific (or source-specific in your terminology).
>
> For example, I would find it very difficult to see how a service such as  
> Netflix's could fit into the model you've defined: we have our own  
> metadata, including categories, and would expect to have our own User  
> Interface on both the TV and the remote: they need to discover each  
> other and communicate but after that their communication probably needs  
> to be proprietary, since standards cannot anticipate the ways we will  
> want to innovate with respect to the Remote<->TV interaction and their  
> respective user interfaces (and nor can I).
>
> I should say that this ability to independently innovate in terms of  
> User Interface and service features has been, and we expect will  
> continue to be, essential to our business. Indeed this is one of the  
> great advantages of integrating web technology into CE devices. The  
> science of content discovery within very large content catalogs has a  
> long way to go: we have had some success with this at Netflix but this  
> is just the beginning. It's not just about good recommendation engines,  
> but about the whole user experience, which is why we need flexible  
> presentation environments on the devices presenting user interfaces and  
> the interaction between them.

I wholeheartedly agree that there may well be aspects of your service,  
particularly its metadata, that cannot be wholly encompassed by an API  
such as the one we have worked on, and that it is important to be able to  
innovate in the remote interface as a part of the service proposition.  
We're hoping that a basic level of metadata and structure could be  
modelled using such an API, but then device/service specific extensions  
could be used to support additional Netflix specific data. This data could  
be used by Netflix specific remote clients.

> On Mar 15, 2011, at 7:49 PM, Matt Hammond wrote:
>
>> Hi Mark,
>>
>>
>> On Fri, 11 Mar 2011 22:32:09 -0000, Mark Watson <watsonm@netflix.com>
>> wrote:
>>
>>> Matt, Olivier,
>>>
>>> The Universal Remote protocol looks great. At what level, though, would
>>> you expect there to be a need for standardization ?

...snipped start of my reply...

>> I'd also be keen to see access to the application layer protocol level
>> abstracted and simplified for common client environments - such as
>> javascript in the browser context. Perhaps this would take the form of
>> client side implementations as device APIs, or as pure javascript
>> libraries.
>
> Javascript libraries would provide a lot more flexibility, unless you  
> thought there might be performance concerns. If there was, for example,  
> an open source client-side library that people could use for their UC  
> implementation you have all the advantages of ease-of-use, avoid (some)  
> problems with divergence features supported by different devices and  
> avoid the difficulty in upgrading devices to support new features. The  
> baked in device APIs would be kept to the lower layer stuff (Zeroconf  
> etc.) that would hopefully be more static.

I agree - Javascript libraries would seem more logical if the inter-device  
protocol is standardised and implementable in javascript within the  
browser context. I don't see there being particular performance concerns.

..snipped outline of domain model..

>>> I can presumably implement both client and server side of the protocol
>>> using HTML/CSS/Javascript (if I can't then there's a need for
>>> standardization right away), so what would remain would be
>>> device/application discovery and the initial security aspects.
>>>
>>> i.e. how does the Universal Remote client discover that there is a
>>> nearby TV supporting the Universal Remote server application (or  
>>> capable
>>> of supporting it) and ask the TV to launch that application (or kick  
>>> off
>>> installation) ?

..snipped discussion of rendezvous/pairing mechanisms..

>> Generally though, for all our use cases, we've considered the server  
>> side
>> to be a device feature, rather than a application with a transient
>> lifecycle.
>
> I don't see an advantage in making things a device feature which could  
> easily be implemented as a web app, given the appropriate platform APIs.

In the context of accessibility, or even just alternative 3rd party  
created remote controls; the ability to control the TV/STB needs to be  
there from the moment it is switched on to the moment it is switched off  
and in all states the box might be in (watching TV or VoD, in menus, etc)  
If implemented as a web app, would that realistically be achievable? We  
also included in our API the ability to bring the device out of standby  
(if the box supports it of course).

This kind of always on service, we think, will also enable innovation in  
the space of 3rd party web content that can integrate with your TV/STB.  
Some examples might include simple programme guide websites that know what  
you are watching and can offer to book recordings, or play recordings or  
on-demand programmes. It might also include dedicated complementary  
content that is time-synchronised to the programme, or social networking  
services that can now know what you are watching. We have proof-of-concept  
demonstrations of many of these concepts using our API. Our spec does  
specifically include support for globally scoped content identifiers, if  
they are available, to enable these kinds of services.

>> In fact there are specific hook points in the API where we'd
>> hope server implementers would make it possible for on-TV applications  
>> to
>> extend the API and have their lifecycle managed by clients. So this API
>> could be a mechanism to achieve what you suggest in your last question,  
>> on
>> behalf of other applications on the TV.
>>
>>
>
> For this aspect, you could also standardize platform APIs that enable  
> people to develop apps (cooperating with remotes or otherwise) for  
> management of other apps, although it is much less obvious that enabling  
> innovation in that space has much value.

Innovation could be in the UI used to do this, particularly for  
accessibility use cases.

As an aside: At the BBC we also have, what we consider 'apps' in the form  
of interactive content delivered via the broadcast stream. Though at  
present primitive, over time these capabilities should become richer and  
we can see value in the ability, for example, to allow viewers to use  
remote clients (eg. an app on their phones) to take part in shared viewing  
interactive experiences. The well trodden example is a quiz broadcast  
where family members can play along whilst watching and their scores are  
collated and compared on the TV screen. This mechanism could support those  
kinds of applications.

cheers


Matt

>>> On Mar 11, 2011, at 9:48 AM, Matt Hammond wrote:
>>>
>>>> Would the Device And Policy APIs WG (DAP) be interested in looking at
>>>> APIs
>>>> not just within the device itself (for accessing on-board device
>>>> functions) but also defining web style APIs between devices?
>>>>
>>>> My personal belief is that the strengths of the TV is as a primary
>>>> (though
>>>> not exclusively!) shared and "lean-back" experience. I think it makes
>>>> sense to put in place the means to allow web applications on other
>>>> devices
>>>> to interact with the TV. A lot of the functions/user-experience that
>>>> might
>>>> traditionally be considered the domain of an on-screen "widget" could  
>>>> be
>>>> migrated off the TV screen to more powerful and easier to interact  
>>>> with
>>>> device, but without losing that connection to the TV content.
>>>>
>>>> Our "Universal Control" API work, in the BBC, makes the functionality  
>>>> of
>>>> the TV queryable and controllable via a high level data model that  
>>>> tries
>>>> to abstract away from device and service implementation specifics.  
>>>> Its a
>>>> RESTful web based API intended to be served by the TV (or set-top-box)
>>>> itself. We'd hope our work so far could be a useful kick start for  
>>>> work
>>>> in
>>>> this area. Components of such an API could be generalised and be  
>>>> useful
>>>> for other classes of devices.
>>>>
>>>> My colleague Olivier posted a few details (including links to our spec
>>>> docs) just a few days ago:
>>>>
>>>>  http://lists.w3.org/Archives/Public/public-web-and-tv/2011Mar/0013.html
>>>>
>>>> Could this kind of area be a logical and productive progression for
>>>> DAP's
>>>> mission?
>>>>
>>>>
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>> On Fri, 11 Mar 2011 16:27:39 -0000, Mark Watson <watsonm@netflix.com>
>>>> wrote:
>>>>
>>>>> [+ Web & TV Interest Group]
>>>>>
>>>>> Should the device types mentioned in the new Device And Policy APIs
>>>>> recharter proposal be expanded to include TVs and other such devices
>>>>> which increasingly make use of web technologies ?
>>>>>
>>>>> ... Mark
>>>>>
>>>>>
>>>>> On Mar 11, 2011, at 5:44 AM, <Ingmar.Kliche@telekom.de> wrote:
>>>>>
>>>>>> Deutsche Telekom supports the new DAP charter proposal [1], but asks
>>>>>> for
>>>>>> some clarifications and/or changes.
>>>>>>
>>>>>> Chapter 1 "Goals" explicitly mentions security and privacy and
>>>>>> proposes
>>>>>> "... reusing existing browser-based security metaphors where they
>>>>>> apply
>>>>>> and looking into innovative security and privacy mechanisms where  
>>>>>> they
>>>>>> don't."
>>>>>>
>>>>>> On the other hand section 2.2. "Out of scope" explicitly excludes
>>>>>> further thinking about a policy framework. This limits the
>>>>>> possibilities
>>>>>> of "innovative security and privacy mechanisms", since one potential
>>>>>> solution is precluded beforehand. We know about the discussions in  
>>>>>> the
>>>>>> past, but we think it should be left up to the discussions during  
>>>>>> the
>>>>>> charter period if a policy framework is the right way to go or not.
>>>>>>
>>>>>> Furthermore the scope of the work explicitly mentions different  
>>>>>> types
>>>>>> of
>>>>>> devices ("Devices in this context include desktop computers, laptop
>>>>>> computers, mobile Internet devices (MIDs), cellular phones.").
>>>>>> Therefore
>>>>>> we think it would be appropriate to add another success criteria  
>>>>>> which
>>>>>> requires implementations for different device types before going to
>>>>>> W3C
>>>>>> Rec (especially mobile and desktop devices) to make sure that the  
>>>>>> APIs
>>>>>> are implementable in the different environments which are explicitly
>>>>>> in
>>>>>> scope of DAP.
>>>>>>
>>>>>> ... Ingmar.
>>>>>>
>>>>>> [1] http://www.w3.org/2010/11/DeviceAPICharter.html
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> | Matt Hammond
>>>> | Research Engineer, BBC R&D, Centre House, London
>>>> | http://www.bbc.co.uk/rd/
>>>>
>>>
>>
>>
>> --
>> | Matt Hammond
>> | Research Engineer, BBC R&D, Centre House, London
>> | http://www.bbc.co.uk/rd/
>>
>


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

Received on Wednesday, 16 March 2011 20:37:37 UTC