W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

[Bug 20992] New: EME should define or reference a platform-independent VM in which CDMs will run

From: <bugzilla@jessica.w3.org>
Date: Thu, 14 Feb 2013 09:18:54 +0000
To: public-html-media@w3.org
Message-ID: <bug-20992-5436@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20992

            Bug ID: 20992
           Summary: EME should define or reference a platform-independent
                    VM in which CDMs will run
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: maratreans@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

The purpose of EME is to replace existing DRM solutions
implemented using non-HTML technologies such as Flash or
Silverlight with a HTML-based solution.  Both these existing
technologies have at their core a platform-independent VM.
To not include a platform-independent VM in EME would be a
step backwards.

A platform-independent VM could be included either by
reference to an existing standard (e.g. Java or .NET) or by
defining a new VM. If a single VM cannot be agreed upon,
another option would be to allow several different VMs.

If a new VM was to be defined, one approach would be to use
ECMAScript + Typed Arrays as the VM. This would be
advantageous in that many browsers already have very good
ECMAScript VMs. A binary encoding for ECMAScript (or a
subset thereof) could be defined to help satisfy CDM providers'
concerns for obfuscation. Existing browsers could easily
translate this binary encoding to standard ECMAScript, or bypass
the textual representation and convert it directly to their own
internal representations of compiled ECMAScript.

Any CDM implemented on a platform-independent VM will
inevitably need to access native services. While these
services themselves are platform-specific, it is possible to
define bindings between VM and native code which are mostly
platform-independent. Consider for example P/Invoke on .NET,
or JNI or JNA under Java. If one or both of these existing
VMs were to be adopted, then these existing technologies
could be used to provide this facility. Alternatively, were
a new VM to be defined (such as my suggestion to base one on
ECMAScript + Typed Arrays), one could define a native
binding API for it based on the model of P/Invoke and JNA.

Some small platform-specific extensions may be required
(e.g. platforms that support multiple calling conventions,
such as Windows), but the binding could be defined in an
extensible manner, and such extensions could be standardised
for all the major platforms. One might also need to provide
an object-oriented binding for those platforms where
object-oriented APIs are prevalent (e.g. COM on Windows,
Objective C on MacOS/iOS), but again the cores of these OO
technologies are similar enough that a common extensible
binding could be shared between them, with some small
platform-specific extensions.

A single CDM could operate on multiple platforms by
dynamically determining what platform it was running on, and
then invoking the appropriate native services for that
platform.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 14 February 2013 09:19:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:58 UTC