[Bug 20963] EME is technically incomplete

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

--- Comment #10 from Zack Martin <maratreans@gmail.com> ---
(In reply to comment #9)
> All this is possible, and could certainly be accomplished in another
> specification (whether created by the W3C or not), but nothing in EME
> technically requires or depends on the existence of such a specification.
Without specifying at this level of detail, the standard contains a massive 
black box, where true interoperability of independently developed 
implementations may well be impossible.

> In fact, it can be argued that the creation of such a CDM API and
> architecture is highly dependent on specific UA implementations, and
> possibly on OS specific ports of such implementations, and, as such,
> should be specified by individual UA vendors.
Need that be the case? One could define a platform-independent virtual
machine  under which CDMs would operate - and there is no reason why such a
VM could not be implemented by any UA on any OS - either one could leverage
an existing such VM (e.g. Java or .NET), or define a new one from scratch 
(which arguably could be simpler than Java or .NET are). With such a VM 
defined, there is no reason why multiple UAs on multiple OSs or hardware 
platforms could not implement it.

Inevitably, any CDM in such a VM may need access to the underlying OS, which
may prevent CDMs from being truly platform-independent. However, there are a
few ways in which platform-dependence can be limited:

1) A single CDM can contain code to integrate with multiple platform's native
services, and dynamically determine which services to use at runtime - thus
the same CDM might operate on iOS, Android, Windows, MacOS X, Linux, etc.

2) Native access to most platforms can be modelled as calls to named
functions (procedural style), or as method invocations on interfaces
(object-oriented style); and there is a common set of data types which will 
address the needs of most platforms (i.e. those provided by C). Such a
strategy might not work for every platform under the sun, but one could
design a native services standard whose basic functions would be equally 
implemented on multiple major OSes, and you could standardise extensions to 
deal with the peculiarities of common platforms (like Windows, Linux, Un*x, 
iOS, etc.)

How the VM code is executed - whether by interpretation, by AOT or JIT
compilation to native machine code, or translation to bytecode of another
VM - these are all implementation details which a standard need not specify. 
But it should define a VM (or VMs) for execution of CDMs.

The existing solutions in this area - both Flash and Silverlight - provide a
a platform independent VM at their core. If EME is to replace this use of
Flash/Silverlight, but does not provide such a VM, it is effectively a step
backwards.

> Given the desire for modularity, layering, and abstraction, EME should not
> be clouded by unrelated implementation details. As such, the CDM mechanism
> in EME is nothing more than a didactic device to aid in the explanation of
> EME processing semantics.
A standard containing a massive black box whose behaviour and interfaces are
insufficiently defined for interoperable implementations to be independently
developed has a major lack.

I don't object in principle to implementing support for DRM. However, if a new 
standard for DRM is going to be proposed in the HTML context, then it should
be superior to the existing Flash/Silverlight solutions, and I believe EME
as currently defined is inferior to them.

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

Received on Thursday, 14 February 2013 08:44:37 UTC