Re: [tvcontrol-api] Management of underlying resources

> Are changes needed to the specification to support this scenario?

Trying to throw some thoughts to trigger discussion here...

The scenario seems to assume that moduleB would only see tuner1 when 
moduleA is done with it. Another possibility would be for `getTuners` 
to return tuner1 regardless of whether the tuner is in use. This does 
not solve the problem though.

If `getTuners` only returns tuners that are free to use, these tuners 
would need to be immediately locked and hidden away from other callers
 as long as the app/module that called the method first does not 
explicitly release them, e.g. through some hypothetical `unlock` 
method. It seems weird to lock resources by default: the app may use 
only one of the tuners returned for instance and requiring it to start
 by releasing tuners it does not need seems bad design: a spec can 
only constrain user agents, it cannot require Web apps to behave in a 
certain way, and thus should no depend on apps doing certain actions 
to unlock resources.

If `getTuners` returns all tuners regardless of their lock state, the 
tuner could be locked once the app starts using it, typically when it 
calls `setCurrentSource`. Unlocking could then be either explicit 
(e.g. a call to `setCurrentSource(null)` would release the tuner), or 
implicit once there are no more references to the tuner instance. In 
that scenario, `tuner.currentSource` and `tuner.stream` must return 
null as long as the app has not called `setCurrentSource` once (an app
 should not be able to see what source another app might have used). 
Similarly, the `currentsourcechanged` event should only be triggered 
for source changes that occur after the initial call to 
`setCurrentSource`.

The lock/unlock mechanism could be more explicit, for instance as done
 in the current draft of the WebVR API for the [`VRDisplay` 
interface](https://w3c.github.io/webvr/#vrdisplay) with the 
`requestPresent` and `exitPresent` methods.

Now, setting the source does not necessarily mean that the app is 
going to *use* the tuner. It seems a bit heavy to lock the tuner right
 away. Wouldn't it be better to lock the tuner once the app actually 
*consumes* content from it, in other words when it accesses the 
`TVMediaStream`?

That would require a change of API, somewhat similar to the discussion
 started in #4 "Why retrieve a list of tuners instead of just one 
tuner". In particular, this would suggest a model à la `getUserMedia`,
 defined in [Media Capture and 
Streams](https://w3c.github.io/mediacapture-main/getusermedia.html). 
In other words, this becomes possible provided the API does not expose
 tuners and sources as objects on which the app can operate.

In terms of WebIDL, something like:
```webidl
interface TVManager {
  Promise<sequence<TVChannel>> enumerateChannels();
  Promise<TVMediaStream> getTunerChannel(TVChannel channel);
};
```

In this model, the notion of sources and tuners may still appear at 
the `TVChannel` level, although as information, not as instances of 
objects that the app may control (no way to switch the tuner to a 
given source, no way to switch a source to another channel). From the 
perspective of this issue, that API would behave the same way as 
`getUserMedia` and release the underlying resource when the 
`TVMediaStream` instance is no longer used. The user agent would be 
responsible for resource management.

Obviously, among other things, I left channels scanning out of the 
discussion there. It could be re-introduced although not at the source
 level, which may be problematic (see issue #7).

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

Received on Friday, 19 August 2016 10:49:13 UTC