- From: <bugzilla@jessica.w3.org>
- Date: Thu, 27 Mar 2014 04:09:18 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750 --- Comment #31 from Joe Steele <steele@adobe.com> --- (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. 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 27 March 2014 04:09:19 UTC