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

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

--- Comment #23 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #22)
> 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.

Ok.

> 
> 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.

I agree. I think base64 would work for us. 

> 
> 
> > 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.

I was thinking of DOMExceptions like InvalidAccessError. In the case of a
corrupted response, the Adobe CDM could throw the DOMException and/or it could
send a keystatus event with "renewalfailed". Probably don't want to do both,
and I would favor the former, but that might be true for everyone.

> 
> 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).

This does not seem like much additional work for the CDM. I believe the browser
can choose not to propagate this event if there are no listeners, but you may
have more insight there. 

> 
> 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"?

Yes - this is the default "all is good" case. "valid" is probably better than
"acquired" since it would make more sense to fire when a key transitioned from
"notyetvalid" to "valid". 

> > "expired", 
> > "notyetvalid",
> > "renewalfailed", 
> > "playbacksexceeded",
> > "authorizationfailed",
> What does this mean? (Remember, this is a per key status.)

This is a way for the CDM to report that a key request failed due to an
authorization error. None of the current DOMExceptions handle this case. E.g. -
the content you are trying to play is no longer allowed on your platform.

> > "outputnotallowed",
> > "downscaling",
> > "released"

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

Received on Wednesday, 17 September 2014 19:06:42 UTC