- From: <bugzilla@jessica.w3.org>
- Date: Thu, 10 Apr 2014 20:29:13 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268 --- Comment #1 from David Dorwin <ddorwin@google.com> --- One of the issues we had during previous discussions is that createSession() always returned a MediaKeySession. With the introduction of Promises (bug 25199), we have the option to not return a session based on asynchronous processing. Thus, instead of creating a useless session object (bug 25267), implementations can reject the promise with an appropriate DOMException if the specified initData was not used to create any of the existing active (i.e. not closed) sessions for this MediaKeys object. This would allow applications to always call createSession() in response to a needkey event while avoiding creation of unnecessary sessions and potentially license requests. We might need a unique DOMException value so that applications can easily check for and ignore this non-error rejection of the Promise. Since the problem described in this bug needs to be solved for all implementations, we would specify this as the behavior for *all* implementations. This would prevent applications from creating a second session for the same initData. If there is a use case for this, we should think about how to allow an application for force this (without releasing the existing session). Since the result is reported asynchronously, the de-duplication of initData can be performed in either the UA or CDM. In either case, existing values should be removed when a session is closed. This does require some extra processing and time for each createSession() call, but it seems worth it to simplify applications. This does *not* solve all scenarios, such as where the initData differs between audio and video streams and the applicaiton only wants to make one license request, but it significantly reduces the number of sessions that are created, especially in adaptive streaming cases. It should also correctly handle key rotation (assuming different initData for different streams is handled correctly). I think this is a significant improvement over the current state, but I would be interested in other proposals, especially if they address the forced session creation and/or different initData issues mentioned above. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 10 April 2014 20:29:15 UTC