This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Various use cases involving loading data from storage have been discussed. While I still think it’s best for interop (and UA implementors) to avoid this as much as possible, it’s probably better to provide a logical mechanism than to have non-standard hacks using createSession() parameters or implicit loading. It also allows the spec to guide such use cases, such as requiring that same origin be enforced. Defining something (even tentatively) will also allow us to focus discussion and explore related issues. I propose adding an optional loadSession(DOMString sessionId) method that is a peer to createSession(). When supported, it creates a MediaKeySession object for the previously created session - specified by |sessionId| - and populates it with data from CDM storage. The new session object follows the same state transitions as other sessions, including possibly firing a message event or moving directly to READY. Since this method is not required for most use cases, it is optional and need not be implemented by user agents or CDMs. Feature detection is simple: * If the user agent does not support loading sessions or knows the keySystem does not, throw NOT_SUPPORTED_ERR. * If the CDM does not support loading sessions (but the user agent did not know this above) fire an error event with NOT_SUPPORTED_ERR at the new session. If the sessionId is not found within the current origin, fire an error event with “NotFoundError” at the new session.
What is the workflow you are proposing for loading previously loaded keys then? Would the application have to keep track of each sessionID it has seen and then try to load them later? I am not sure how this is intended to solve the general problem of CDM data storage. Is that the intent?
This looks good to me and would enable us to close the key release bug. To answer Joe's question, yes, applications would need to track previously created sessions and their ids and then use that information to reload a previously established session if needed. I think this explicit knowledge / control of session storage is cleaner than having the CDM do this transparently. The application can store this information in IndexedDB / WebStorage. If that is cleared, the stored sessions in the CDM should probably be cleared anyway.
(In reply to Joe Steele from comment #1) > What is the workflow you are proposing for loading previously loaded keys > then? Would the application have to keep track of each sessionID it has seen > and then try to load them later? I am not sure how this is intended to solve > the general problem of CDM data storage. Is that the intent? The proposal for loadSession implies that CDMs will be able to store keys between browsing sessions. Calling loadSession with a sessionID that would be stored locally in some JavaScript enabled mechanism (e.g. localstorage or IndexedDB) would ask the CDM to reconstitute the MediaKeySession from whatever it stored. I think this means that the goal of avoiding general CDM data storage has been dropped. I think this is a good approach. The implementation of the method is optional (not the method itself) - it will throw if this isn't supported by the CDM. Assigning to David.
To be resolved: Can the same session (ID) be loaded multiple times without closing the previous MediaKeySession? (Note that applications cannot force a MediaKeySession to be closed while keeping it "stored" since release() frees the stored session.) If not allowed, should a "QuotaExceededError" MediaKeyError be fired on subsequent attempts?
(In reply to David Dorwin from comment #4) > To be resolved: Can the same session (ID) be loaded multiple times without > closing the previous MediaKeySession? > (Note that applications cannot force a MediaKeySession to be closed while > keeping it "stored" since release() frees the stored session.) > > If not allowed, should a "QuotaExceededError" MediaKeyError be fired on > subsequent attempts? When I was thinking about text for this I wondered if it was required that a loaded session always got the same session ID as the original or might it be allowable for a CDM to create a session that gets a new ID. Since we don't currently have implementations for loadSession I think we should describe it as narrowly as possible (for example, you can only load a session once, it always gets the same session ID as the original). Then, if we find an implementation that has a requirement to relax the rules we can do that but this way we keep the surface area as small as possible until we know we need more.
I added a first pass at this to the spec. https://dvcs.w3.org/hg/html-media/rev/154207f5ed25
This looks good to me. Thanks. I made some minor changes in https://dvcs.w3.org/hg/html-media/rev/1c0406dd179f
Added origin checks: https://dvcs.w3.org/hg/html-media/rev/65700f185389