[Bug 25923] isTypeSupported should be asynchronous

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923

--- Comment #18 from David Dorwin <ddorwin@google.com> ---
(In reply to Boris Zbarsky from comment #17)
> > This does not describe the current form of the API.
> 
> Ah, thank you.  So I'm not sure what the point of the API in the form it's
> in is, then.  A UA can just always return "maybe", which is not helpful.

If the user agent does not support a key system or the user has completely
disallowed it, the user agent can return "". "maybe" means the application
should try it if there are no "probably" responses. (The application could
still prefer "maybe" if it really liked that combination, but it should be able
to handle failure.)

> > For example, one possible solution would be to return "maybe" (or some other
> > relevant value) in the case where the CDM is not yet downloaded.
> 
> Sure, but then the page would want to know when the download is done so it
> can ask again, right?

In such a design, the application might call MediaKeys.create(), which would
generate the prompt and download as appropriate. If the prompt was declined,
the promise would be rejected. Otherwise, the promise would be resolved when
the CDM has been installed.

> I'm not tied to a particular solution, but I do think that we want an API
> here that is actually useful to web pages and that can handle the "answer is
> not known yet, but will be known pretty soon" situation.  I'm quite open to
> how that API should look, though typically for modern web APIs it would
> involve returning a Promise for the value.

I mostly agree. I think the discussion is whether isTypeSupported() should
return the promise or create(), which already returns a promise, should handle
this. (Or perhaps there is some other solution.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 28 August 2014 00:28:52 UTC