Re: [w3ctag/spec-reviews] TV Control Feedback (#111)

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 `MediaStream`s 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()`:

```js
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](http://json-schema.org/)

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!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/111#issuecomment-257746605