Re: [tvcontrol-api] API surface and REST-based approach

Some thoughts below to capture my understanding of the TAG's comment.

I believe there are 3 main models that may be used to design the TV 
Control API:

1. A **hardware centric** model. This more or less matches the current
 spec, and we're now moving away from it. The interfaces get 
introduced in a way that simplifies the mapping onto the underlying 
hardware. This simplifies implementation in theory. However, this 
approach is not flexible in practice. It cannot easily integrate more 
advanced use cases (e.g. online sources not directly linked to a 
tuner, constraints of more advanced decoding circuits, tuners that can
 return more than one streams at once)
2. An **internal source-centric** model. This is more or less what 
we're heading to in current group discussions. In this model, the 
TV/Radio box is seen as an internal device, exposed through an API, 
that can produce one or more media streams. Through parameters, the 
application can constrain the stream, e.g. to switch to another 
channel, enable/disable particular tracks. This model is close to 
"getUserMedia" (which deals with cameras and microphones), although 
the parameters to constrain the tracks are of different nature in the 
case of the TV Control API.
3. An **external source-centric** model. This is my understanding of 
what the TAG proposes here. In this model, the TV/Radio box is seen as
 an external endpoint that can provide one or more media streams. The 
application can send requests to this external endpoint to apply 
additional constrating on a media stream using HTTP requests 
(WebSockets could work too) with specific command messages. From a 
media stream perspective, the external endpoint could be represented 
as a sort of `RTCPeerConnection` and the application could perhaps be 
given an `RTCRtpReceiver` instance per media stream track. Or perhaps 
the media stream could be represented as a dereferenceable HTTP URI in
 that model.

I would say that the main advantage of the internal source-centric 
model is that the API exposed to the developer can remain 
straightforward: the developer will directly interact with the objects
 exposed by the API. One drawback is that it requires buy-in from 
browser vendors to implement the different facets of the API.

One advantage of the external source-centric model is that the 
implementation of the TV/Radio box remains mostly external to the 
browser runtime. In other words, the conformance class of the 
specification would be the TV/Radio box in this model, not the user 
agent. One drawback is that things are a tad more complex for 
developers who now need to prepare and wrap commands to the external 
endpoint in HTTP/WebSockets calls. This model also triggers a number 
of open questions, including how to represent media streams (whether 
it is a good idea to pull the RTC stack for instance), how to push 
events from the TV/Radio box onto the client, at which location to 
expose the endpoint, how to address synchronization/latency issues.

A couple of possible questions for the TAG:

1. Does that more or less capture the proposed idea?
2. Would you be making the same comment to "getUserMedia" if it 
started over again today?


-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/tvcontrol-api/issues/24#issuecomment-261918951 
using your GitHub account

Received on Monday, 21 November 2016 12:02:07 UTC