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

Thanks for clarifying. There were no specific reasons the current design
does not use objects. It just started as an additional method and evolved
from there.

On Sun, Jun 24, 2012 at 9:38 PM, Glenn Adams <glenn@skynav.com> wrote:

> My understanding is that the current proposed design does not use a
> state/session object, and that you are considering adding one. My question
> is why the current design rationale did not propose such an object in the
> first place? From the "disadvantages" below, all I see is a complexity
> argument or a new object argument. That just doesn't seem like much
> rationale for keeping the existing approach. Thus my question if there is
> more to it.
>
> My preference is using a separate state/session object. The complexity
> argument is too weak.
>
> On Sun, Jun 24, 2012 at 9:53 PM, David Dorwin <ddorwin@google.com> wrote:
>
>> Hi Glenn,
>>
>> We didn't understand what you were asking in the last EME telecon. Are
>> you suggesting using an object that gets passed around to the existing
>> methods (in place of sessionId) or why the original draft did not use
>> objects?
>>
>> David
>>
>> On Mon, Jun 11, 2012 at 10:17 PM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>> 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.
>>>>
>>>
>>>
>>
>