Re: [mediacapture-main] getUserMedia algorithm should be made more synchronous

> First, a natural mapping to old-style callback APIs throwing 
exceptions is for promise-based APIs to return a rejected promise.

Is the significance of returning an "already rejected promise" that 
it's immediately observable in the JS debugger? If so then I think I'm
 coming around.

I think the point you're making here is that 3.2. amounts to trivial 
argument validation not entirely unlike what WebIDL binding code 
performs automatically if passed `1` instead of `{}` (returning an 
already-rejected promise with `TypeError`). E.g. a future version of 
WebIDL may even grow a way to express [AtLeastOneMemberPresent] or 
some extended attribute like that, in which case we'd wish we'd made 
3.2. synchronous.

In hindsight, we should perhaps even have considered `TypeError` 
instead of `NotSupportedError`, since the latter is somehwat 
misleading. Yes `{ lasers: true }` resulting in `NotSupportedError` 
sounds good, but `{ lasers: true, audio: true }` succeeds without 
error.

> Second, is there any good reason to implement step 3.2 
asynchronously?

As @adam-be mentioned, I think it moved to stay with the structure of 
the algorithm, to keep the number of steps low, which has some value. 
But the "go to step x" pattern seemed more of a win with the old 
callbacks than with the new less verbose "reject p" language. Maybe 
it's time to rethink that.

-- 
GitHub Notif of comment by jan-ivar
See 
https://github.com/w3c/mediacapture-main/issues/174#issuecomment-106966303

Received on Saturday, 30 May 2015 00:21:53 UTC