If we are already making this a method, we might consider having that method return a promise that provides the Array<Uint8Array> when resolved. This avoids tracking the array in the MediaKeySession and having the CDM update it. However, the CDM is already calling into the MediaKeySession to fire the keyschange event. A promise-based solution would allow user agents to choose either implementation.

After this is resolved, we should change the loadSession() algorithm to *not* update the array when constructing the new MediaKeySession. It's probably better to be consistent and always fire the keyschange event.

The invalid part here is the Array<> bit.

You should also not use #idl-array.  It's slated for removal from the IDL specification.

Either return an ES array object (using "sequence" or "object" depending on how you're doing it) or return an instance of an interface with an indexed getter.

The pattern we try to advocate people to use for now is return an object (as IDL does not allow returning a sequence) and define in prose that you return a JavaScript Array Object that represents a snapshot of the underlying data. Whenever you update the underlying data, you also need to create a fresh snapshot object. 

So you end up with two variables (underlying data, Array object) and an update algorithm.

(In reply to Anne from comment #3)
> The pattern we try to advocate people to use for now is return an object (as
> IDL does not allow returning a sequence) and define in prose that you return
> a JavaScript Array Object that represents a snapshot of the underlying data.
> Whenever you update the underlying data, you also need to create a fresh
> snapshot object. 
> 
> So you end up with two variables (underlying data, Array object) and an
> update algorithm.

Are you saying that the following is the recommended style?
  object getUsableKeyIds();

Is that preferred to asynchronously looking up the data only when queried? For example:
  Promise<object> getUsableKeyIds();
where the promise is resolved with an object that is a JavaScript Array Object that represents a snapshot of the underlying data.

>Are you saying that the following is the recommended style?
>  object getUsableKeyIds();

In this case, you could do:

  sequence<Uint8Array> getUsableKeyIds();

or:

  attribute object usableKeyIds;

with the latter having prose that describes when the object is created, etc.

> Is that preferred to asynchronously looking up the data only when queried?

Not particularly, no.  Sync vs async is a separate API decision from what type results from the API call; they are not tied to each other.

It seems per comment 1 asynchronous might be better to allow flexibility in implementations. In that case I would recommend a method that always returns a new promise that at some point resolves with a snapshot of the underlying data. The IDL you want in that case reads:

  Promise<sequence<Uint8Array>> getUsableKeyIds();

(In reply to Anne from comment #6)
>   Promise<sequence<Uint8Array>> getUsableKeyIds();

I support this proposal, as it seems to me that managing the list of usable keys is the business of the CDM. This way, the browser can just query the CDM for its keys when getUsableKeyIds() is called, and we don't have to worry about keeping a copy of the keys in the browser up to date.

We'll implement the promise version in the previous comments.

https://dvcs.w3.org/hg/html-media/rev/c02fbe3a2c13

Changeset https://dvcs.w3.org/hg/html-media/rev/c4a18d018444 tweaks some of the changes in c02fbe3a2c13 and updates the example to use the promise returned by the new method.

(In reply to David Dorwin from comment #1)
> After this is resolved, we should change the loadSession() algorithm to
> *not* update the array when constructing the new MediaKeySession. It's
> probably better to be consistent and always fire the keyschange event.

Updating the array was removed as part of changeset c02fbe3a2c13.
In https://dvcs.w3.org/hg/html-media/rev/75051d4bb6a7, I made loadSession() run the Usable Keys Changed algorithm for consistency with created sessions and update(). Specifically, the "keyschange" event will fire in both cases.