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

Source/modules/encryptedmedia/MediaKeySession.cpp

 /*
  * Copyright (C) 2013 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 31 matching lines @@
     return adoptRef(new MediaKeySession(context, cdm, keys));
 }
 
 MediaKeySession::MediaKeySession(ExecutionContext* context, ContentDecryptionModule* cdm, MediaKeys* keys)
     : ContextLifecycleObserver(context)
     , m_keySystem(keys->keySystem())
     , m_asyncEventQueue(GenericEventQueue::create(this))
     , 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);
 }
 
 MediaKeySession::~MediaKeySession()
 {
     close();
 }
 
 void MediaKeySession::setError(MediaKeyError* error)
@@ skipping 40 matching lines @@
         // The user agent will asynchronously execute the following steps in the task:
 
         // 1. Let cdm be the cdm loaded in the MediaKeys constructor.
         // 2. Let destinationURL be null.
 
         // 3. Use cdm to generate a key request and follow the steps for the first matching condition from the following list:
         m_session->generateKeyRequest(request.mimeType, *request.initData);
     }
 }
 
-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)
         return;
 
     while (!m_pendingKeys.isEmpty()) {
         RefPtr<Uint8Array> pendingKey = m_pendingKeys.takeFirst();
 
         // NOTE: Continued from step 2. of MediaKeySession::update()
         // 2.1. Let cdm be the cdm loaded in the MediaKeys constructor.
@@ skipping 55 matching lines @@
 {
     return EventTargetNames::MediaKeySession;
 }
 
 ExecutionContext* MediaKeySession::executionContext() const
 {
     return ContextLifecycleObserver::executionContext();
 }
 
 }