Re: Encrypted Media Extension bugs for discussion during 2012-06-12 teleconference

I changed the table to plain text below so it is hopefully more readable in
the archives.

On Mon, Jun 11, 2012 at 5:40 PM, David Dorwin <ddorwin@google.com> wrote:

> In the first HTML WG media teleconference, we will discuss as many of the
> following Encrypted Media Extension bugs as we can get through. (See
> http://tinyurl.com/7tfambo for a full list.) I've provided some brief
> notes for each bug below the list. I'll also start threads for some of
> them.
>

ID Sev Pri OS Assignee  Status Resolution  Summary
16612^ nor P1 All adrianba@microsoft.com NEW ---  Consider wrapping all
encrypted media methods inside a new interface
16613 nor P1 All adrianba@microsoft.com NEW ---  Consider a more
object-oriented design in which sessions are represented as objects
16548 nor P2 All adrianba@microsoft.com NEW ---  Require
generateKeyRequest() in all cases for all Key Systems
16549^ nor P2 All adrianba@microsoft.com NEW ---  Remove initData parameter
from addKey()
16552 nor P2 All adrianba@microsoft.com NEW ---  Consider making needkey a
simple event
16738 nor P2 All adrianba@microsoft.com NEW ---  Provide more guidance on
heartbeat implementation
17199 nor P2 All adrianba@microsoft.com NEW ---  Provide examples for and
get feedback on Key Release

^ We will defer discussion of these since they depend on other bugs in this
> list.
>
>
> * 16612: Read for background, but we will defer discussion until we decide
> on 16613.
> * 16613: This is the most important since so many other bugs depend on or
> are affected by it. I've added some pros and cons as well as references to
> many other bugs that may be at least partially addressed by objects. There
> is a link to a formatted version of the bug in Comment 3<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613#c3>
> .
> * 16548: Summary: Making the uncommon simplest case slightly more complex
> simplifies implementation and increases consistency.
> * 16549: Read for background, but we will defer discussion until we decide
> on 16613 and 16548.
> * 16552: Are there strong preferences for simple vs. complex events? Note
> that we could consider making all events simple if we address 16613.
> * 16738: How should heartbeats be implemented? keymessage followed by a
> reply using addKey() or as separate key requests/sessions?
> * 17199: It would be good to get more feedback in the area of key release,
> especially regarding whether KeyReleaseManager should be a singleton and/or
> a member of window.
>