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

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

--- Comment #39 from David Dorwin <ddorwin@google.com> ---
I think we have agreement that a maplike structure mapping key ID to status
should be exposed to applications and that it should be separate from
MediaKeySession. The remaining question is how best to expose it to
applications.

The basic questions we need to answer are:
1. Do we want to provide a copy?
 Pros:
  * A copy avoids changes while iterating through the list.
 Cons:
  * Either of the synchronous solutions could reintroduce this problem (i.e.
repeated calls to session.getKeyStatuses() rather than calling it once and
using the returned object).
  * Applications must continually obtain a copy if they want to check the
statuses independent of the keyschange event (i.e. stream change logic).
  * Prevents observing the object (in the future).

2. Should access be synchronous?
 Pros:
  * Simple for applications.
  * Allows the statuses to be used in synchronous logic (i.e. stream changes)
in addition to in response to keyschange events.
 Cons:
  * Forces user agent implementations to always receive/obtain the key statuses
whenever there is a change (before firing the keyschange event).
   - How problematic would this be?
   - Are there implementations that would not want to do this?
  * Based on the Priority of Constituencies, the pro should outweigh the con.
However, the answer might be different if the con results in a bad experience
for users (i.e. performance).


We have the following three options, each of which has pros and cons related to
the questions above.

A. Attribute: readonly MediaKeyStatuses keyStatuses;
Pros:
 * Simple for applications to use and can be used in synchronous logic.
 * Can provide a reference instead of a copy (if we choose to specify this in
the algorithms).
  - This would allow MediaKeyStatuses to be made observable (in the future).
Cons:
 * It is not clear whether a copy is provided just by looking at the IDL.
 * Implementations must always have the latest list from the CDM, regardless of
whether the application uses it.

B. Synchronous method: MediaKeyStatuses getKeyStatuses();
Pros:
 * Still simple for applications to use and can be used in synchronous logic.
 * Slightly more clear that a copy is being provided.
Cons:
 * It is still possible to write code where the list changes while iterating.
 * Implementations must always have the latest list from the CDM, regardless of
whether the application uses it.
 * This would be the only MediaKeySession method that does not return a
promise.
  - Would that be confusing for authors?

C. Asynchronous method: Promise<MediaKeyStatuses> getKeyStatuses();
 Pros:
  * Clear that a copy is being provided.
  * Implementations can choose to obtain the key statuses only when the
application requests them.
  * Returning a promise is consistent with all other MediaKeySession methods.
 Cons:
  * Adds (likely) unnecessary complexity to applications.
   - In response to an asynchronous event, the application must make an
asynchronous request for the data related to that event.
  * Could this add a very minor delay to the application?

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

Received on Wednesday, 12 November 2014 23:31:17 UTC