[Bug 26372] Report issues/events not related to a specific method call

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|adrianba@microsoft.com      |ddorwin@google.com

--- Comment #17 from David Dorwin <ddorwin@google.com> ---
There are currently two proposals (comment #15), both of which involve an enum.
The first provides an indication of the reason for the change in status. The
second provides the current status for each key ID. We should pick one and move
forward. I will probably do so soon.

#1) Add an enum to the "keyschange" event that indicates the reason it was
fired.
Pros:
 * Simple to implement and use.
Cons:
 * No indication of which key(s) the reason refers to.
 * Requires defining another custom event type instead of reusing Event.
 * Multiple such events:
  - They may need to be correlated to get a full picture.
  - getUsableKeyIds() may not reflect the reason in the event.

#2) Replace getUsableKeyIds() with a function that returns a list of all known
key IDs along with their current status.
For example: Promise<sequence<Object>> getKeyStatuses();
Pros:
 * Exposes detailed information about the current state to the application.
 * No loss of information due to multiple changes and related events.
 * It seems more extensible.
Cons:
 * More complexity for CDM implementations.
 * More processing for applications.
 * Must return a Sequence of pairs or two Sequences. (The correct solution for
returning such data in a Promise is TBD.)

In the example above the Object would be a JSON object with two fields: the
base64url-encoded key ID and the current status as an enum value.


In either case, we also need to determine the enum values. At a minimum, we
need some type of "license window exceeded" value and "outputprotection".

The former could be broken out into "expired", "renewalfailed", "outsidewindow"
or "notyetvalid", "playbacksexceeded", and/or other values. We need to provide
sufficient granularity for applications without baking in specific policies or
implicitly ruling out other policies in the future.

We could also have a value for key IDs that have been encountered in media data
but are unknown to the session. This would indicate that the correct license
has not yet been provided or the license contained the wrong key IDs.

The default value should be the empty string, which will allow it to be used as
a Boolean just like the canPlayType() result.

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

Received on Tuesday, 16 September 2014 23:50:41 UTC