TV Control API

[torgo]

Discussed at London f2f 30-March-2016.

[yfuna]

The tech spec worth to be reviewed for this purpose is: TV Control API Specification

Note that the work items in the TV Control WG scope is incubated in the TV Control API CG. The CG created a spec called TV Control API which is based on an early version of the TV Manager API Mozilla developed. This is an API-based approach but the WG is flexible about methodology: API or URL.

[torgo]

Document has moved to the TV Control WG.

[torgo]

Discussed at Stockholm f2f.

[torgo]

Let's catch up with whoever is working on this at TPAC. @yfuna do you need to hear from us before then?

[plinss]

Will invite WG members to a future call

[travisleithead]

Note, added https://github.com/w3ctag/design-principles/issues/33.

[travisleithead]

Taken up at Tokyo F2F: Main GitHub repo: https://github.com/w3c/tvcontrol-api/

High-level Use Cases Requirements Technical Requirements

[travisleithead]

TAG Review Feedback

• We are excited to see the web moving into even more application domains.
• We feel that the use-cases are thought out pretty fully.
• We would like to see example code. The current draft and use-cases docs are too light on this.
• The spec envisions two scenarios: Controlling a TV/DVR and controlling TV playback through a <video> tag
  • The WebRTC model has many parallels in regards to the objects/structures used to both find media and consume the media. Unlike RTC end-points, TV controllers do not need to negotiate for discovery because a client can know whether a local TV tuner is installed. However, from the POV of the Tuner, there is still an entire channel/program/stream discovery that must take place--and that's where we start to see many parallels. If we consider integrating the TVTuner (and related interfaces) into an object that is obtained from a negotiation with something on the server that is producing the media, then that object becomes a central control point from which APIs can be defined that configure/constrain that stream. (It also allows ambiguity for the TVTuner to be either a local or remote/network based source--in a similar way to how RTC MediaStreams represent either local camera/mic control sources or over-the-network remote streams).
• Overlap between Media Recorder and Recorder APIs in TV Control -- wondering why we'd need separate use cases.
• In general (and this is not solely an issue with TV Control), there is a problem with divergent approaches taken to media streams in w3c specifications. We would like to see some efforts to unify these. For TV Contol specifically, we would suggest a liason with the WebRTC WG, webaudio, audio source input/output. A liaison with TTML may also be useful.
• Some of the control surfaced looked like it could be a problem if curious uses cracked open developer tools to tweaked values in script, for example parental control pin info :-)
• We're wondering if new APIs in this style might be phrased in a way that has a smaller API surface area, e.g., HTTP request/response or Service Worker Foreign Fetch (https://developers.google.com/web/updates/2016/09/foreign-fetch)
  • May be possible to model many of the APIs here as locally-provided HTTP services; e.g. this: https://w3c.github.io/tvapi/spec/#tvsource-interface

Might instead be modeled as a set of requests and responses via fetch():

fetch("https://example.com/services/v1/channels")
   .then((resp) => {
      resp.json().then((channels) => {
         console.log(channels);
      });
   });

Open issues with a design like this involve a standard location for such an RPC interface and a format for the returned data. This seems like a good thing for a TV control interface spec to define, perhaps using a system like JSON Schema

It's also unclear how the event-sending side of this might work, but we're confident that can be overcome in the Foreign Fetch model, perhaps by allowing FF responses to contain MessagePort objects.

@yfuna there's a lot of feedback here, and it might be useful to have a discussion at one of our telecons. If you're interested we can get something scheduled at an upcoming call. Thanks!

[torgo]

Noted semi-factiously in our Boston TAG f2f: We think this API should be able to control the horizontal and control the vertical.

[travisleithead]

Specifically, according to w3c/tvcontrol-api#24, it looks like things are trending in the right direction. Excited to see how this develops.

[cynthia]

I've raised issues on this separately when the initial draft was being minted - those are still open, aside from that not much to add.

Should we close this?

[travisleithead]

From @travisleithead in w3c/tvcontrol-api#24,

At this point, we will likely want to wait and see how this develops, as it seems as if the spec hasn't taken some of the changes you're currently thinking about.

[cynthia]

The group's new charter was rejected, so the group is most likely closing down - meaning this isn't going to ship. I suggest we close this.