16550 2012-03-28 00:22:54 +0000 Should sessionId checks in addKey() and cancelKeyRequest() be synchronous? 2012-08-17 06:05:20 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED FIXED P3 normal --- 16613 16548 1 ddorwin ddorwin eric.carlson mike philipj public-html-media public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 66165 0 ddorwin 2012-03-28 00:22:54 +0000 From v0.1: Should this be handled {in the synchronous portion of the addKey() algorithm} or in the task scheduled in the next step. The advantage of handling it here is that what is likely a programming error is immediately and simply reported via an exception. The disadvantage is that the user agent must store session IDs (and track when they are released) for each Key System rather than letting the CDM manage them. This is inconsistent with the goal that the user agent should just pass information. This same issue also applies to cancelKeyRequest(). 66166 1 ddorwin 2012-03-28 00:26:38 +0000 The related text in the cancelKeyRequest() algorithm from v0.1 is: Can this step^ be done synchronously or should a task be queued to do it in the background and a needkey event fired when done? ^ The step is: Clear any internal state associated with the sessionId (or if this is null with the keySystem for this media element). This sessionId will now be unrecognized. 68930 2 ddorwin 2012-06-11 23:57:37 +0000 I think this issue could be obsoleted if we removed sessionId parameters by encapsulating the session in an object as proposed in bug 16613. 72334 3 ddorwin 2012-08-17 06:05:20 +0000 Addressed by the object-oriented API (bug 16613). addKey() and close() no longer have sessionId parameters to check.