答复: FW: [EME] object-oriented design representing sessions as objects

I think it is a good idea, and I have question on this.
Have you update the bug16613 by your proposal, I have not seen the changes you mentioned.
If  you mean add a HTMLMediaElement object in session object or needkey event, Do we need a method in session object or event interface to change
The status of MediaElement so it can fire a event to application?

Do we have a method called cascade event chain possible in HTML, that if event A fires, event B depend on A will fire too.







发件人: David Dorwin [mailto:ddorwin@google.com]
发送时间: 2012年6月19日 11:34
收件人: Chen, Michael
抄送: public-html-media
主题: Re: FW: [EME] object-oriented design representing sessions as objects

Thanks Michael. I thought some more about this and updated the bug with the text below.


As Michael Chen pointed out, if the events are no longer fired at HTMLMediaElement there is no way to relate the event back to the original element to which it pertains in the proposed API.

Do we need to be able to relate the event and elements when the events are communicating information about the session?

If so, the element could be a property of the event or the session object. Sharing session objects between elements could complicate this; maybe not associating the session/events with elements is better for this reason.


The proposal also moves the needkey event to the object, but a session may not always exist when a needkey event needs to be fired (encrypted block or potentially encrypted stream encountered). Maybe this event needs to continue to target HTMLMediaElement. This probably makes sense if there is only one initData per session. It's TBD if there are cases where needkey should be fired at the session object.

On Wed, Jun 13, 2012 at 6:57 AM, Chen, Michael <Michael_Chen@cable.comcast.com<mailto:Michael_Chen@cable.comcast.com>> wrote:
>mc: if we move to the session object if we have async events that fire on
>the object how do you relate this back to the original element to which
>it pertains
>
>ddorwin: i guess the event would need to have a property for the element
>... that's good feedback
>... could you make this comment on this list?


Sent from my Android phone using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

________________________________
From: Paul Cotton
Sent: Wednesday, June 13, 2012 1:32:21 PM
To: Chen, Michael
Subject: FW: [EME] object-oriented design representing sessions as objects

From: David Dorwin [mailto:ddorwin@google.com<mailto:ddorwin@google.com>]
Sent: Tuesday, June 12, 2012 12:58 AM
To: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: [EME] object-oriented design representing sessions as objects

[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.