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

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

--- Comment #35 from David Dorwin <ddorwin@google.com> ---
(In reply to David Dorwin from comment #34)

Another option is to make the maplike object a member of MediaKeySession or to
return it from a MediaKeySession method. This would separate the collection
from the session. For example:

enum MediaKeyStatus { "valid", "expired", "outputprohibited", ... };

interface MediaKeyStatuses {
  readonly maplike<BufferSource, MediaKeyStatus>;
};

interface MediaKeySession : EventTarget {
  ...
  readonly MediaKeyStatuses keyStatuses;
};

This is the Web IDL equivalent of adding the following attribute:
  readonly map<BufferSource, MediaKeyStatus> keyStatuses;

Usage would then be, for example, session.keyStatuses.get(keyId).


This proposal is essentially the same as providing a sequence (discussed
previously), but it provides a more useful interface for authors. It is also
similar to what Boris suggested in
http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0025.html but we
now have Web IDL support.

One of the issues with exposing the map as a member or from a member method is
whether such a member returns the actual object, which can be updated, or a
copy, which will not receive updates. (This is similar to the discussion in
comment #24.) However, even with the proposal in comment #34, we were relying
on the keyschange event to tell the application to look at the map. Thus, a
copy doesn't seem so bad, especially if it prevents the members from changing
as I noted in the last paragraph of comment #34.

Authors could still get unexpected results if they wrote iterative code that
referenced the member repeatedly. For this reason and to allow asynchronous
communication with the CDM (rather than the user agent caching the statuses),
we should probably use a promise-returning method:

interface MediaKeySession : EventTarget {
  ...
  Promise<MediaKeyStatuses> getKeyStatuses();
};

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

Received on Monday, 10 November 2014 23:58:16 UTC