Re: [mediacapture-record] Should stop(), pause(), resume() change state synchronously?

@foolip Since "as is" is that the spec does not match implementations, except for `start()`, aren't the options:

   1. Fix remaining spec methods to set state synchronously + comment that it's a historical accident
   2. Measure how often state is accessed in the interim where it would change before deciding whether to fix `start` method to be async like the rest, and fix implementations.

?

I've had this in the back of my mind for a while, and I think I'm leaning toward this:

> Pretend that the state changes synchronously anyway, and queue a task to fire events. Media elements mostly work like this.

I think it should lead to fewer races in practice. Except for `"inactive"`, all [state](https://w3c.github.io/mediacapture-record/MediaRecorder.html#enumdef-recordingstate) is caused by JS methods anyway. In the case where a recording ends or terminates because of failure, it seems like we can resolve races in the task queued to set state to `"inactive"`, by basically flushing anything that went before as belonging to the recording that just terminated.

Not seeing much practical benefit of going full async at this point. Even if we have the methods return promises, we'd still need to resolve races somehow, either like this, or using a queue of some sort.

Common usage wouldn't see any difference:
```js
await rec.start();
log(rec.state + " for "+ (ms / 1000) +" seconds..."); // recording for 5 seconds
```

Btw, when looking at the async steps in the spec, please see https://github.com/w3c/mediacapture-record/issues/131, which I just filed.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/123#issuecomment-322245568 using your GitHub account

Received on Monday, 14 August 2017 16:55:22 UTC