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

[Bug 17750] Define the behavior MediaKeySession close() and clearing the keys attribute

From: <bugzilla@jessica.w3.org>
Date: Mon, 14 Oct 2013 21:54:31 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-17750-2486-ygxOMKZhBC@http.www.w3.org/Bugs/Public/>

--- Comment #10 from Adrian Bateman [MSFT] <adrianba@microsoft.com> ---
(In reply to David Dorwin from comment #9)
> What changed between comment #5 and comment #8? What scenarios/concrete
> examples are we trying to address? (Also, see the reply to comment #7 below.)

What changed was thinking about Joe's comments and also reading Mark's comments
in bug 17199.

> > With our proposal for the MediaKeySession state model, two different
> > MediaKeySessions could be responsible for acquiring the same key. This means
> > that calling close() on one session doesn't offer any guarantee that a
> > particular key is released. In addition, the way many CDMs are likely to be
> > implemented, keys will be passed to the media engine and their lifetime
> > managed there.
> We need to address the behavior around such "shared" sessions if we choose
> to move forward with the proposal in comment #8. If close() is just a hint
> (see below), is it up to the CDM to decide what to do? Whenever "shared"
> sessions are closed by the CDM, both should probably receive the CLOSED
> event.

Since I wrote that I've proposed that there is no explicit sharing - just that
you don't necessarily need to go through PENDING to get to READY.

> > I propose that we remove the close() method from the MediaKeySession in v1
> > unless we have a concrete example from on implementer of how they will use
> > it. In that case, the language of the spec should make close only a hint to
> > the CDM that may be ignored.
> Should we be more explicit about close() being a hint in the proposal in
> comment #8?

I don't think we can be. I wonder if we can start with saying there are no
guarantees and see if we run into implementation problems? Are there specific
guarantees you are looking for?

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 14 October 2013 21:54:33 UTC

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