Bug 16550 - Should sessionId checks in addKey() and cancelKeyRequest() be synchronous?
Should sessionId checks in addKey() and cancelKeyRequest() be synchronous?
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P3 normal
: ---
Assigned To: David Dorwin
HTML WG Bugzilla archive list
:
Depends on: 16613
Blocks: 16548
  Show dependency treegraph
 
Reported: 2012-03-28 00:22 UTC by David Dorwin
Modified: 2012-08-17 06:05 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 2012-03-28 00:22:54 UTC
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().
Comment 1 David Dorwin 2012-03-28 00:26:38 UTC
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.
Comment 2 David Dorwin 2012-06-11 23:57:37 UTC
I think this issue could be obsoleted if we removed sessionId parameters by encapsulating the session in an object as proposed in bug 16613.
Comment 3 David Dorwin 2012-08-17 06:05:20 UTC
Addressed by the object-oriented API (bug 16613). addKey() and close() no longer have sessionId parameters to check.