RE: TAG discussion on the TV Control WG charter

Hi Colin,

You make some very good points here, thank you.

As Igarashi-san has said, I think so far we've considered the TV Control API as a way to expose broadcast-delivered media and metadata into the browser environment, which has naturally led us to a JavaScript API, but we should be open to considering alternative approaches IMO.

I think this is something that the WG should continue to consider and discuss, and would be worthwhile exploring further what a network resource based approach to our API might take.

Thanks again,

Chris (WG Chair)

________________________________________
From: Meerveld, Colin [C.Meerveld@activevideo.com]
Sent: 10 May 2016 12:48
To: Chris Needham; public-tvcontrol@w3.org; public-tvapi@w3.org
Cc: Igarashi, Tatsuya
Subject: Re: TAG discussion on the TV Control WG charter

Hi Chris,

That is a very good question. From my experience, i see that specific APIs mostly lag behind the practical need, is usually less generic and harder to abstract.
Therefore i believe that it is very hard for the W3C to maintain all those specific APIs in the future.

In the Cloud Browser TF [1] we really face this problem.
We defined some use cases/requirements for capabilities and constrains [2] for example.
Some of them could be mapped to existing device APIs but most should be expose by other means.

A solution could be to treat each functionality as a "network resource”.
Note that "network resource" could be exposed via a generic standardised API (IMO the resource URL should be omitted. i.e. it is more or less a "network resource" from a User Agent perspective).
This API should enable the application to listen to a available "network resources", see the capabilities and use there functionality.

An example could be a pvr which is a specialised type of a generic storage device and could be abstracted (i.e. for the application it shouldn't make any different if it is a local-pvr or network-pvr).
In contrast with the TVRecording interface , which is very specific to broadcast tv.

I fully agree with Tatsuya that some functionality should be treated differently.
I.e. controlling a tuner could be done with a "network resource" where the (conceptional) rendering is done with the media element (though there is theoretically nothing wrong to see a "media display" as a network resource, especially with multi-screen applications).

Thanks,

Colin meerveld
Platform Architect
ActiveVideo

[1] https://www.w3.org/2011/webtv/wiki/Main_Page#Cloud_Browser_Task_Force
[2] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/communication#capabilities_and_constrains

On 09 May 2016, at 09:05, Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>> wrote:

Hi Chris,

W3C has been promoting to diverse devices using web technologies in past 5 years. This is a fundamental issue if device specific capabilities should be exposed as network resource or JavaScript APIs as W3C standards. It would be appreciated if TAG provides a guideline on the two approaches. Also, it is preferable that W3C defines a basic framework to convert W3C standard APIs(Web IDL) to "network resource" approaches using REST and WebSocket. In the era of IoT, it would be good for web application developers to control devices regardless of device location.

In terms of TV Control API[1], it should be JavaScript API  because it is not only about controlling TV but also for integrating broadcast rendering function (of device) in browser's implementation. TV Control API defines an extension to the HTML5 video in order to support broadcast specific requirements. I found the following two use cases in the TAG's minutes. TV Control API is for UC1 but not UC2. I wonder that the word "Control" may cause some misleading. TV Control API is not designed for UC2.  "network resource" approach, e.g. REST, would be good enough to change channel of remote TV device but the TV Control API is required to extend HTML video in addition to such controls.

UC1. a TV running FFOS that wants to manipulate internal state through an API that they want to expose.
UC2. I'm a generic web browser and I want to connect to a set-top-box and I want a protocol to talk to that device.

The other issue of "network resource" is security. Mixed Content[2] requires to use TLS connection to local server on device if a web page is secured, but devices may not be able to have a FQDN server cert. This issue is generic because it applies the case that a web server on IoT devices become a part of Open Web.  UC2 has the same issue as discussed at TPAC2015[3]

Thank you.

[1] http://www.w3.org/2015/tvapi/Overview.html
[2] http://www.w3.org/TR/mixed-content/
[3] https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Secure_communication_with_local_network_devices

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Innovative Technology Development Div, System R&D Group
Sony Corporation



-----Original Message-----
From: Chris Needham [mailto:chris.needham@bbc.co.uk]
Sent: Friday, May 06, 2016 9:39 PM
To: public-tvcontrol@w3.org<mailto:public-tvcontrol@w3.org>; public-tvapi@w3.org<mailto:public-tvapi@w3.org>
Subject: TAG discussion on the TV Control WG charter

Hi all,

The TV Control WG Charter was discussed by TAG at their recent F2F meeting [1]. The minutes from the meeting are at [2] and [3].

In summary, the TAG is wondering whether specific APIs such as ours, and others coming from other groups such as the Automotive WG, could perhaps be best exposed as network resources rather than JavaScript APIs, however they do not currently have specific guidance on which approach to take.

There was initially some confusion about the scope of the TV Control API, which Yosuke helped clarify during the meeting. This is understandable as the name could be read to imply a protocol for controlling a TV device on the network, which isn't really the aim of our WG.

Nonetheless, the question of whether a network resource based approach would work hasn't been discussed in the CG so far, and we'll need to have a view on this when we start discussion with the TAG.

Please share your comments on the mailing list.

Thanks,

Chris (WG Chair)

[1] https://github.com/w3ctag/spec-reviews/issues/111
[2] https://github.com/w3ctag/meetings/blob/gh-pages/2016/03-london/29-03-2016-minutes.md
[3] https://github.com/w3ctag/meetings/blob/gh-pages/2016/03-london/30-03-2016-minutes.md





-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Friday, 20 May 2016 15:47:04 UTC