- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Oct 2013 21:54:31 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750 --- 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