[Bug 25268] Reduce the burden on applications to deduplicate initData from many needkey events

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jdsmith@microsoft.com,
                   |                            |watsonm@netflix.com
         Resolution|FIXED                       |---

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
tl;dr: The current solution is broken and does not help many applications.
Thus, I propose removing all deduplication of initData from the spec and
implementations.


Thinking about this more, I have two concerns about the solution (comment #3).

1) While the solution reduces the number of sessions created (particularly for
a very simple needkey => createSession() app), it does not reduce the burden on
other apps, especially those that do not want a separate session for each
unique initData.

For such apps, the comparison occurs *after* the application needs to
deduplicate initData - the app needs to determine whether to create a session
before calling createSession(), so it is still deduplicating all the initData
from all needkey events. The app could see whether it gets a session when the
promise is resolved, but that seems hacky.

What such applications really need is to avoid receiving the needkey event.
Since initData comparison an be implemented in the user agent, we could do
this, but:
 * The HTMLMediaElement would need to interact with its MediaKeys object before
firing the event, which seems odd.
 * There was previously a desire to allow applications to receive all such
events.

2) The current solution has a race condition between checking the "list of
active session Initialization Data" and adding a session created by another
call being added to the list. The intent was to avoid adding a session until it
was successfully created, but this causes non-deterministic behavior.

Instead, a session needs to be added immediately after checking (and
implementations need to make these two steps atomic) and removed if there is a
faiulre. This could result in no session being created for a given initData if
the first createSession() call failed. This seems acceptable and the
application can also retry when the first promise is rejected.


It might just be better to give applications full flexibility (Why does the UA
really care if there are duplicate sessions?) and provide best practices for
handling needkey events for various application models.

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

Received on Wednesday, 18 June 2014 23:54:33 UTC