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

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

--- Comment #32 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #31)
> (In reply to David Dorwin from comment #30)
> > (In reply to Joe Steele from comment #29)
> > > Would that use case cause a problem? I could see an app calling update()
> > > which causes a license to be cached and then on receiving release(),
> > > immediately tearing down the session. That should be fine. 
> > 
> > I assume you mean "cause a license to be stored persistently...".
> > 
> > If so, release() would cause it to be erased from persistent storage.
> > release() is *not* close() - it actually releases all resources related to
> > the session. See the discussion starting at Comment 16.
> 
> Sorry - I should have been more clear. What I was saying is that the license
> would be persisted to disk AND then erased as part of the release() when the
> session is torn down. I was not suggesting that the license would be
> retained. You seemed to be indicating this might be a problem, which is what
> I was triggering off of.

I think I was thinking of something like the key release model where the update
might need to be processed before releasing the session. I didn't have an exact
use case in mind.

The reason an application might call update(response); release(); is that there
is no way to wait for an update to be processed. Promises would address this
(as well as other yet to be resolved issues in this bug) - see bug 25199.

> Having said this -- I don't know how I will support this yet. I am not happy
> with the idea of tying a set of opaque key server responses to a session. It
> is unclear how applications will be able to determine which sessions to load
> or release without having visibility into the key server responses. This
> either restricts the key server severely in what keys it can return OR it
> places an additional burden on the application to be parse key responses to
> determine exactly what it in them. I don't have a better proposal at this
> point though.

What is "this" that you need to support? I don't follow this paragraph or how
it relates to this bug and close().

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

Received on Saturday, 29 March 2014 00:41:19 UTC