Spec promise<bool> IsConfigSupported()

[chcunningham]

This tracks spec work to offer a static asynchronous API to check whether a given configuration is supported.

Calling configure() with a valid but unsupported configuration will trigger a fatal error (see #53) via the error callback. Validity can be assessed synchronously and throw an exception. Support is harder because it may require async checks (e.g. if a given codec is only available via hardware acceleration, such acceleration typically happens in a separate process and may require IPC to verify details of support).

Our first thought was to have configure() return a promise, but this has a few drawbacks:

1. the only other async->promise API is currently flush(), and its promise indicates that the flush has been completed. having configure() return a promise to indicate that its configuration is supported (but not necessarily applied) is inconsistent and hard to reason about.
2. If we attempt to address 1 by only resolving once the configuration is supported and applied, realtime users may suffer visible side-effects of needing to react to a preventable failure at the last minute

So instead we offer this static async API which users should call prior to calling configure().

[padenot]

So instead we offer this static async API which users should call prior to calling configure().

Whether a configuration is supported is a dynamic affair, not a static one. There is a gap of time in between getting the answer and calling configure.

If we have two calls, then it's well possible that the first call is a success and the second one is a failure (say, going in battery saving mode, unplugging a GPU, driver issue, resource contention on hw codec, etc.), or the opposite. We can decide to do it, but this needs to be clear (as an informative note or something).

[sandersdan]

Removing the promise from configure() was a huge improvement to complexity and removed a lot of edge cases for the Chrome implementation. Specifically:

• If we return a promise, it's only useful (compared to an error callback) if apps wait for it to resolve before enqueuing chunks.
• This increases latency compared to other fallback strategies (unless we discard chunks queued after the configuration, which is likely to explode the state machine in the implementation and in apps).
• This prevents us from deferring configuration changes. In some cases we don't have a signal better than 'we tried to decode a chunk and it succeeded/failed', so we want to be able to defer configuration until we have a chunk.

I vote that isConfigSupported() should be best-effort indication.

[chcunningham]

I vote that isConfigSupported() should be best-effort indication.

+1. I'll update the PR accordingly.