[Bug 26575] Separate creation of the MediaKeySession from "message" event generation

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

--- Comment #17 from David Dorwin <ddorwin@google.com> ---
(In reply to Shinya Maruyama from comment #14)
> "Store keySession.sessionId in the application" needs to be moved after
> generateRequest is resolved because sessionId attribute is not available at
> the timing above.

Thanks for catching this. Fixed in
https://dvcs.w3.org/hg/html-media/rev/3a5e8f5332a2.

> Essentially this seems to be the API design issue. I believe application
> should store the sessionId before the session data is persisted within
> update() to avoid application losing the sessionId. However, as the
> generateRequest is asynchronous, the API can no longer expect that sessionId
> is made available to the application before update() unless the application
> takes a special care for the timing.

The sessionId is known when the promise returned by generateRequest() is
resolved. This should be well before a "message" event can be handled,
including a server roundtrip. In theory, "callable" could be set to true and
update() called before the resolve function(s) on the promise are run. If this
was an issue, the application could either delay the update() call or ensure
that the sessionId is stored before calling update() (the sessionId is
guaranteed to be valid before "callable" is true). Another option would be to
save the returned promise and use it in update():

  var generatePromise = session.generateRequest();

  function handleResponse(response) {
    generatePromise.then(
      function {
        session.update(response);
      }
    );
  }

This works because generatePromise.then() will always call the resolve function
once it's been resolved. Of course, I don't think there is any guarantee that
the other resolve function will run before this one, so this might need some
tweaking.

We've basically moved the very real and common timing issue of firing the
"message" event before a listener can be added in a promise resolver to a
theoretical issue of update() being called before the sessionId can be recorded
in a promise resolver. I'm open to suggestions on algorithmically addressing
this issue.

> The sessionId should not be removed at the timing if remove() requires
> message exchange(s).

Step 5.2.1 of the remove() algorithm guarantees that the resolve function is
not called until the message exchange completes. This was intentional to handle
this scenario.


The rest of the discussion appears unrelated to this bug.

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

Received on Wednesday, 27 August 2014 18:01:29 UTC