- From: <bugzilla@jessica.w3.org>
- Date: Wed, 13 Feb 2013 23:51:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20963
Zack Martin <maratreans@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |maratreans@gmail.com
--- Comment #8 from Zack Martin <maratreans@gmail.com> ---
It could be made more technically complete as follows:
- Introduce a requirement that CDMs be downloadable and executable in a sandbox
-- Possible sandboxes might be JVM, .Net, NaCl, etc. Rather than require one
particular sandbox, implement a registry of sandbox IDs, and some way to
request a particular version of that sandbox (e.g. Java version >= 7)
-- Have an XML manifest for the CDM that declares:
---- CDM identity and revision number
---- what sandbox it uses and what revision
---- URL from which it can be downloaded
---- list of native OS services it requires, if any
------ this list may be platform-specific, e.g. Windows API X from Y.dll
Linux function X from Y.so. Define a naming scheme that works for
common platforms, e.g. win32:dllname:exportname,
linux:dllname:exportname
make it extensible to support further platforms
------ a sandbox specific API to invoke those native services. This could be
e.g. P/Invoke under .NET, JNA under Java, etc.
---- UA or sandbox must verify the CDM, either before executing it or while
executing it, to ensure it only uses the declared native services. How the
UA or sandbox should do so would be sandbox-specific.
With this design, it should be possible for a CDM to work with multiple UAs or
even multiple platforms. Of course, there are no guarantees - the CDM could
always detect the UA or platform and refuse to run - but it means that building
a UA or platform restricted CDM becomes more of a conscious decision and less
of
an accident.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 13 February 2013 23:51:32 UTC