[mediacapture-record] Async algorithms .start(), .stop(). pause() et al. need major work

jan-ivar has just created a new issue for 
https://github.com/w3c/mediacapture-record:

== Async algorithms .start(), .stop(). pause() et al. need major work 
==
The fundamental design of async algorithms should be:
 1. You do some stuff synchronously up front to make sure the API call
 makes sense, and throw if not.
 1. You return.
 1. You do async stuff like waiting, fetching, etc. [*in 
parallel*](https://html.spec.whatwg.org/#in-parallel).
 1. Any further communication with your original caller happens from 
tasks you post to a task source.

Compare this to the `.start()` algorithm (and most of the others):
 1. Queues a task immediately on the *DOM manipulation task source* 
(effectively the main thread!).
 1. It never returns.
 1. It throws exceptions from a queued task, which never make it back 
to content.
 1. It blocks the main thread with language like "wait until media 
becomes available".
 1. It fires events like `stop` synchronously from code that seems 
asynchronous, causing JS concurrency.

I suspect all the algorithms that queue to *DOM manipulation task 
source* and then wait should be rewritten this way. Some like 
`.resume()` may be fine as-is, though I'm curious why we seem to 
prefer changing state on the next event loop rather than 
synchronously?

Please view or discuss this issue at 
https://github.com/w3c/mediacapture-record/issues/54 using your GitHub
 account

Received on Thursday, 14 April 2016 16:23:37 UTC