This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16613 - Consider a more object-oriented design in which sessions are represented as objects
Summary: Consider a more object-oriented design in which sessions are represented as o...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 16549 16550 16612 16614 16615 17199 17203
  Show dependency treegraph
 
Reported: 2012-04-03 16:16 UTC by Mark Watson
Modified: 2012-08-17 04:09 UTC (History)
7 users (show)

See Also:


Attachments

Description Mark Watson 2012-04-03 16:16:19 UTC
A variant of the API with the same functionality has been suggested in which key exchange 'sessions' are explicitly represented as objects. The methods used to supply a key/license or cancel the session become methods on this object, not the HTMLMediaElement itself.

partial interface HTMLMediaElement {
    MediaKeySession generateKeyRequest(in DOMString keySystem, in Uint8Array? initData);
};

interface MediaKeySession : EventTarget {
    readonly attribute DOMString keySystem;
    readonly attribute DOMString? sessionId;
    
    void addKey(in Uint8Array key);
    void cancel();
};
The following event would be fired at the MediaKeySession when a message is ready to be sent.

[Constructor(DOMString type, optional MediaKeyMessageEventInit eventInitDict)]
interface MediaKeyMessageEvent : Event {
    readonly attribute Uint8Array message;
    readonly attribute DOMString? defaultUrl;
};

dictionary MediaKeyMessageEventInit : EventInit  {
    Uint8Array message;
    DOMString? defaultUrl;
};
Note that in the MediaKeySession interface, sessionId is guaranteed to be initialized only after the first MediaKeyMessageEvent.

The following event would be fired at the MediaKeySession when the transaction is complete. (It could be replaced by a simple event.)

[Constructor(DOMString type)]
interface MediaKeyCompleteEvent : Event {
};
Finally, the following event would be fired at MediaKeySession if getKeyRequest() or addKey() results in an error.

[Constructor(DOMString type, optional MediaKeyErrorEventInit eventInitDict)]
interface MediaKeyErrorEvent : Event {
    readonly attribute MediaKeyError errorCode;
    readonly attribute unsigned short systemCode;
};

dictionary MediaKeyErrorEventInit : EventInit  {
    MediaKeyError errorCode;
    unsigned short systemCode;
};
Comment 1 David Dorwin 2012-05-25 22:16:56 UTC
Bug 16612 also relates to improving encapsulation.

The Media Source Extensions effort is also discussing whether to encapsulate the methods should be in separate object - see bug 17082. We should track the progress there.
Comment 2 David Dorwin 2012-05-25 22:34:39 UTC
Bug 16615 presents another use case where such an object might be helpful.
Comment 3 David Dorwin 2012-06-11 22:07:54 UTC
A formatted version of the original bug report can be found at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-oo-api-design.
Comment 4 David Dorwin 2012-06-12 00:04:36 UTC
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

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.
Comment 5 Yang Sun 2012-06-12 07:50:17 UTC
1. why we specify this type: uint8array for message? why not just using string or not specify the type?

2. why we always have xxxEventInit for each type of event? what's the intention of this xxxEventInit?
Comment 6 Mark Watson 2012-06-12 15:33:51 UTC
(In reply to comment #5)
> 1. why we specify this type: uint8array for message? why not just using string
> or not specify the type?

This is the appropriate type for a sequence of bytes. A string is a sequence of unicode characters. The type needs to be specified because scripts need to be written that handle these messages (for example to send them to a remote server) without embedding keysystem-specifics in the script.

> 
> 2. why we always have xxxEventInit for each type of event? what's the intention
> of this xxxEventInit?

This is just the standard pattern for providing initialization parameters to an object constructor.
Comment 7 David Dorwin 2012-06-19 03:27:43 UTC
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.
Comment 8 Adrian Bateman [MSFT] 2012-07-10 15:41:44 UTC
Per telcon, next step is to incorporate this proposal: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html

See ACTION-1: https://www.w3.org/html/wg/media/track/actions/1
Comment 9 David Dorwin 2012-08-17 04:09:23 UTC
The object-oriented design discussed on the list is now published. See http://lists.w3.org/Archives/Public/public-html-media/2012Aug/0027.html