FW: Polyfill example

I am moving this EME Editor-only discussion to public-html-media@w3.org<mailto:public-html-media@w3.org> so that all HME WG members are aware of the discussions about an EME test suite.  Please continue the discussion on this thread.

FTR the original discussion can be found starting at:
https://lists.w3.org/Archives/Public/public-hme-editors/2016Jun/0099.html


/paulc
HME WG Chair

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, June 23, 2016 2:27 AM
To: public-hme-editors@w3.org; Greg Rutz <g.rutz@cablelabs.com>
Subject: Polyfill example

All,

As an example I created an (admittedly messy) polyfill for the pseristent session types for Clear Key.

You can see it here: https://github.com/mwatson2/web-platform-tests/blob/clearkey-success/encrypted-media/clearkey-polyfill.js


If you include this script, it will add support for the persistent session types to a browser that supports only the "temporary" session type for Clear Key. Since Clear Key is not robust, we can implement the persistence / usage recording in JS.

My persistent session type test cases (in the same branch) pass with this polyfill.

There are some issues, which I can work on if there is interest in the general approach:

  *   I don't have test cases for retrieving a MediaKeySession in a new browsing session. I'm not sure how this should be done in web-platform-tests ? For example, how do we test that IndexedDB or even localStorage actually store data across browsing sessions ?
  *   (As a consequence of the above, there are likely some bugs remaining in the polyfill)
  *   I made up the release message format for the persistent-license session type, which is not in the specification for Clear Key. I wonder if we should add it ? I will open an issue to track discussion of that.
  *   Exactly which keys are being used is not exposed to JS, so for the moment the persistent-usage-record case is recording all the time that an attached media element is playing content, independent of whether that content is encrypted with the keys available in the session. (I'm not sure how we could fix this, other than by intercepting MSE and parsing the stream for key ids and timestamps. This would be lot of work and I think unnecessary for proving the design / interoperability of the API).
  *   Chrome doesn't seem to fire keystatuseschange on session close (or I have mis-understood something or there is a bug in the polyfill) and so I updated my test to match the implementation rather than the specification. One or the other needs to be fixed.
I do think this experiment demonstrates that we can run tests against an implementation which is part native part Javascript and I think this is valid for demonstrating the API design. IIUC, some chunks of the browser itself are implemented in JS anyway.

...Mark