Re: DAP rechartering discussion

One more comment way below ...

On Mar 16, 2011, at 1:37 PM, Matt Hammond wrote:

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

I could imagine the web environment being there right from the beginning on the TV or STB - the first thing it does out of the box being to start up some default app with the manufacturers UI.

If I have some remote application it finds the TV using some low-level mechanism and, once securely associated, requests it to run some different app - one that pairs with my remote application in some way.

The device features are limited to the discovery, secure app launch capability. The Javascript APIs on the device need to expose device features (like TV channel and other playback, recording, ESG access etc.). Think about all device behaviour being controllable by Javascript, so all TV watching happens "inside" one app or another, rather than "beside" the app. It's not a contradiction for the server side of a remote UI to itself be an application provide all device functions are visible from the app environment.

...Mark


> 
> 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 22:46:06 UTC