[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
----------------------------------------------------------------------------
                 CC|                            |ppergame@google.com,
                   |                            |strobe@google.com

--- Comment #22 from David Dorwin <ddorwin@google.com> ---
There are a lot of options even within the three main proposals. I think we
need some input from authors that intend to use this information on which
approach, formats, etc. would be most useful.

(In reply to Joe Steele from comment #19)
> I propose something between #1 and #2. 
> 
> Let's create a keystatus event which includes a status enum, a key ID and a
> system code. The CDM would send this event any time a keys status enum
> changes. This would supersede keyschange and getUsableKeyIds().

Thanks. This is definitely an approach to consider. Let's call it #3.

For reference, below is possible IDL for this custom event type.

enum MediaKeyStatus { ... };
interface MediaKeysChangeEvent : Event {
  readonly attribute MediaKeyStatus status;
  readonly attribute sequence<ArrayBuffer> keyIds;
};

Note that I did not include the systemCode (see below) and I've used a sequence
of keyIds (as discussed in my concerns below). Also, I'm not sure whether we
should represent key IDs with an ArrayBuffer or base64url-encoded string (see
below). Any of these could be addressed with minimal changes to the IDL below.

Regarding system code, let's see how bug 26776 is resolved. Any interface-based
solutions would allow it to be added if that is deemed appropriate. However,
the system code seems less important here, especially if we have fairly
detailed enum values, than category I.A. errors.

Most of the proposals use an ArrayBuffer to return the key ID in binary. This
makes sense on the surface, but I'm not sure it's the best solution for
applications. If the application wants to track events, it might be simpler to
just compare and/or index by a base64url-encoded representation of the key ID.
It may even use this format to communicate to the server. Returning a DOMString
or string representation in a JSON Object may make more sense for applications
and avoid unnecessary conversions. Since the purpose of this event/method is to
allow the application to understand and manage the returned data, I think it's
important that the data is easy for the application to use.


> Pro - 
> * Easy to consume on the app side
> * More flexible for apps
> * Easier to implement for browsers/CDMs
> 
> Con - 
> * App has to track all such events if it cares
> * App has to maintain state structure if it cares
> * Key statuses might overlap with other errors?
Do you have specific overlaps in mind? I don't think we have overlap between
I.A. and I.B. of comment #0.

Other concerns:
* The number of events that would be fired, especially when a license is first
acquired and there are many keys (i.e. key rotation scenario). At least these
events should be fired rarely.
* While per-key events might be helpful in some cases (i.e. "I can use the high
resolution stream now"), it could be difficult for applications to get a
"snapshot" of the current state. When handling any specific instance of the
event, the application won't know if there are more events to come.
Specifically, a single change in state (i.e. expiration or release) could cause
multiple events to be fired.
* Using an array for the key ID (see above).
* The CDM must always do the work to generate the event details even if the
application is not listening to the event. (This is one reason we decided to
use a Promise in bug 25594 rather than just returning the array.) I'm not sure
how much of a burden this is (beyond the work involved in triggering the basic
"keyschange" event).

One possible solution to my second concern would be for the custom event type
to have a Sequence of key IDs instead of a single ID.

> I suggest the following enum values:
> "acquired",
Is this the default valid case? How about "valid" or "usable"?
> "expired", 
> "notyetvalid",
> "renewalfailed", 
> "playbacksexceeded",
> "authorizationfailed",
What does this mean? (Remember, this is a per key status.)
> "outputnotallowed",
> "downscaling",
> "released"

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

Received on Wednesday, 17 September 2014 18:28:13 UTC