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.

Document has moved to the TV Control WG.

Discussed at Stockholm f2f.

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

Will invite WG members to a future call

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

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

High-level Use Cases Requirements Technical Requirements

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!

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

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

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?

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.

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.