Re: [EME] object-oriented design representing sessions as objects

What is the rationale for not using a state/session object?

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

> [This is the most important open Encrypted Media Extensions bug because so
> many other bugs depend on or are affected by the potential use of objects.]
>
> One of the open issues in the proposal is whether to have a more
> object-oriented API that has the same functionality but represents key
> exchange 'sessions' as objects. In this variant, most of the methods,
> properties, and events would be on this object rather than
> the HTMLMediaElement. An potential design is shown at
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-oo-api-design
> .
>
> The issue is tracked in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613. We'd like to have
> some discussion on this topic and make a decision so we can move forward on
> the bugs that depend on this decision.
>
> Below is my evaluation of the potential change from comment 4 in the bug.
> Please comment on, add to it, and/or provide other feedback. There seem to
> be a lot of advantages, and the main disadvantages are seem to be potential
> extra work for implementations and possible separation of every initData
> into a separate object.
>
> Advantages of the object-oriented approach:
>  * Clearly defines the lifetime of a session. (See also 16547.)
>  * keySystem and sessionId do not need to be passed around - they are
> always
> properties.
>  * We might be able to eliminate cancel[KeyRequest]().
>  * Minimal changes to the HTMLMediaElement interface and better
> encapsulation
> of this functionality.
>  * May allow sharing of keys between multiple elements if the object can be
> associated with additional elements. (See also bug 17202.)
>  * Might allow us to use properties on the object with simple events
> instead of
> using complex events.
>  * Addresses at least some aspects of bug bug 16547, bug 16548, bug 16550,
> bug
> 16612, bug 16614, 16615, bug 17199, bug 17202, bug 17203 <see the bug for
> titles and links>
>
> Disadvantages:
>  * Additional complexity for implementations?
>    - Association of sessions with elements _might_ be more difficult.
>    - Another IDL, and implementation.
>      * For WebKit, we currently just add some methods on the existing media
> element stack. A new element would require implementing a new stack to get
> to
> the embedder.
>  * Additional complexity for applications?
>  * If we tie the generateKeyRequest() functionality to this object, each
> new
> license (and every unique init_data) would create a new object. This could
> apply to relatively simple cases, such as separate files (and keys) for
> audio
> and video. (In the existing proposal, a separate session ID would be
> created,
> but all interaction would be through the same object - the
> HTMLMediaElement.)
>
> TBD:
>  * The impact of firing events at the new object instead of the
> HTMLMediaElement on applications.
>  * It would be nice to have some input on what might be preferable from an
> application developer POV.
>  * Whether Media Source will move in a similar direction - consistency
> would be
> nice. See bug 17082.
>  * Should new objects be automatically associated with a media element?
> Should
> there be some "static" creation method (or just new "MediaKeySession") that
> provides an object that can be added to an HTMLMediaElement. This would be
> similar to xxxTracks as discussed in bug 17082 comment 4.
>