W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2013

[Bug 19809] Specify which portion of addKey() algorithm to run when updating license for a key

From: <bugzilla@jessica.w3.org>
Date: Tue, 29 Oct 2013 00:40:16 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-19809-2486-Q7V7XMXGCw@http.www.w3.org/Bugs/Public/>

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
(In reply to David Dorwin from comment #0)
> #2 If so, should we say "For each individual key _represented_ in |key|"
> since these subsequent licenses may not actually specify the key itself
> again?
Other information related to keys may be stored, though not explicitly listed
in the steps. The storage algorithm specifically relates to keys, so I think
it's fine as is.

More importantly, the key storage algorithm describes deleting and replacing
keys but does not specify the context - that is, whether it is within the
session or the MediaKeys. This text was originally written in the context of
HTMLMediaElement, so it is referring to MediaKeys. However, deletion is
probably not the right action when sessions overlap.

I'm leaning towards deleting the key storage algorithm and noting that it is
CDM specific. I think overlapping keys should not be deleted such that when one
session is closed, an overlapped key in another session is available.

(In reply to David Dorwin from comment #0)
> It
> probably makes sense to always "attempt to resume playback" because it's
> possible that the new license will allow previously stalled playback to
> resume.
There may be cases where no new key is stored (as in the current algorithm) but
playback becomes possible. Given this and the possible removal of the key
storage algorithm, we may want to remove "did store key" and always try to
resume playback when waiting for a key.

Finally, |key| is a misleading and inappropriate name for update()'s parameter.
We should rename it. I can file a separate bug, but this is a good context to
be thinking about that as well.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 29 October 2013 00:40:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:45 UTC