MediaKeySession: update(key) -> update(response).

Source/modules/encryptedmedia/MediaKeySession.cpp

Index: Source/modules/encryptedmedia/MediaKeySession.cpp
diff --git a/Source/modules/encryptedmedia/MediaKeySession.cpp b/Source/modules/encryptedmedia/MediaKeySession.cpp
index 0760ee356b0780ba0127f132c6ea8d9771a48813..6b00db12f5c386e3b95c67905703171cd9e6f3a7 100644
--- a/Source/modules/encryptedmedia/MediaKeySession.cpp
+++ b/Source/modules/encryptedmedia/MediaKeySession.cpp
@@ -49,7 +49,7 @@ MediaKeySession::MediaKeySession(ExecutionContext* context, ContentDecryptionMod
     , m_session(cdm->createSession(this))
     , m_keys(keys)
     , m_keyRequestTimer(this, &MediaKeySession::keyRequestTimerFired)
-    , m_addKeyTimer(this, &MediaKeySession::addKeyTimerFired)
+    , m_updateTimer(this, &MediaKeySession::updateTimerFired)
 {
     ScriptWrappable::init(this);
 }
@@ -110,23 +110,25 @@ void MediaKeySession::keyRequestTimerFired(Timer<MediaKeySession>*)
     }
 }
 
-void MediaKeySession::update(Uint8Array* key, ExceptionState& exceptionState)
+void MediaKeySession::update(Uint8Array* response, ExceptionState& exceptionState)
 {
-    // From <http://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-addkey>:
-    // The addKey(key) method must run the following steps:
-    // 1. If the first or second argument [sic] is null or an empty array, throw an InvalidAccessError.
-    // NOTE: the reference to a "second argument" is a spec bug.
-    if (!key || !key->length()) {
+    // From <https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-update>:
+    // The update(response) method must run the following steps:
+    // 1. If the argument is null or an empty array, throw an INVALID_ACCESS_ERR.
+    if (!response || !response->length()) {
         exceptionState.throwUninformativeAndGenericDOMException(InvalidAccessError);
         return;
     }
 
-    // 2. Schedule a task to handle the call, providing key.
-    m_pendingKeys.append(key);
-    m_addKeyTimer.startOneShot(0);
+    // 2. If the session is not in the PENDING state, throw an INVALID_STATE_ERR.
+    // FIXME: Implement states in MediaKeySession.
+
+    // 3. Schedule a task to handle the call, providing response.
+    m_pendingKeys.append(response);
+    m_updateTimer.startOneShot(0);

[ddorwin, 2014/01/07 01:10:43]

abarth: Is it preferable to use Blink timers to "Schedule a task to..." or to
use Chromium's PostTask?

Doing this in Chromium would seem to give us more control over which thread and
maybe allow us to be more precise at which step we start the task. However, this
might mean more of the algorithm steps would be in Chromium. We'll need to keep
this in mind as we get further in implementation, but I'm curious about best
practices too.

[ddorwin, 2014/01/07 02:41:21]

Looking at the steps in the algorithm, there may not be steps that we want more
control of. We may even want to do some of the similar createSession() task in
Blink (e.g. steps 4.3 and 4.4).

The main disadvantage of posting the task in Blink might be:
 * An unnecessary post if we end up posting in the Chromium code.
 * The task still runs on the main thread.
On the other hand, posting the task here enforces a clear barrier between the
synchronous and asynchronous parts of the algorithm regardless of what happens
in the more complex Chromium code.

[xhwang, 2014/01/07 17:33:53]

I like posting the task here so that:
* Blink impl is close to the spec
* Chromium impl doesn't need to worry about sync/async.

I agree that this may end up with an extra post if Chromium also does a post.
But I don't feel it's a big performance issue because the whole
MediaKeys/MediaKeySession operations are relatively inexpensive/infrequent
compared to the media demuxing/decoding.

 }
 
-void MediaKeySession::addKeyTimerFired(Timer<MediaKeySession>*)
+void MediaKeySession::updateTimerFired(Timer<MediaKeySession>*)
 {
     ASSERT(m_pendingKeys.size());
     if (!m_session)