Re: [EME] Requiring generateKeyRequest() in all cases for all key systems

This change doesn't seem to be controversial, but we'll need to figure out
how to implement the check. I added the following comment to the bug:

One option is that the user agent should fire an INVALID_STATE_ERR if addKey()
or cancelKeyRequest() are called before an appropriate (i.e. same keySystem)
successful call to generateKeyRequest().

However, should we also require a valid session ID (bug 17203
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17203>), which would
also require that generateKeyRequest() had been called? Note that the current
draft says to throw an INVALID_ACCESS_ERR if sessionId is unrecognized.
However, that assumes the session ID check is synchronous, which may not make
sense (bug 16550 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16550>).

This discussion may be moot depending on the specific solution to bug
16613 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613>. [1]

[1] See also the discussion at
http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0054.html.

On Tue, Jun 19, 2012 at 8:33 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>  On Jun 11, 2012, at 10:49 PM, David Dorwin wrote:
>
>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=16548
>
>  The proposal currently allows addKey() to be called without
> calling generateKeyRequest(). This allows a very simple application as
> shown in the example in section 7.1. However, such applications are
> unlikely and supporting this adds complexity to implementations. Therefore,
> I would like to always require generateKeyRequest(). Does anyone object?
>
>  The impact on the example in section 7.1 is shown in
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-disallow-addkey-only-example
> .
>
>  Benefits include:
>  * Simplifies user agent implementation - there is one API where a CDM can
> be instantiated.
>  * We can eliminate the keySystem parameter from addKey() and
> clearKeyRequest()
>  * Less confusion in the application and user agent related to the
> potential for the keySystem value to change, such as in addKey() and
> clearKeyRequest() calls.
>  * It fits nicely with an object-oriented design, such as the one proposed
> in bug 16613.
>
>
>  I agree.
>
>  …Mark
>
>