[Bug 24082] Several issues discussed in the TF point to the need for defined extensibility points in EME

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082

--- Comment #7 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #6)
> (In reply to David Dorwin from comment #4)
> > (In reply to Joe Steele from comment #1)
> > The examples below all seem related to authentication and authorization.
> > From the EME Abstract:
> > “The common API supports a simple set of content encryption capabilities,
> > leaving application functions such as authentication and authorization to
> > page authors.”
> 
> This would in no way remove control from the hands of the page authors. It
> does remove some of the constraints around how authentication and
> authorization are conveyed to the server.
Not only does this principle put applications in control, it keeps the EME APIs
and specification simple and consistent across clients.

> > > 2) Information/instructions to manage cached state
> > These sound like control messages, which are different than the message
> > passing of update() and keymessage. I don’t think extending createSession()
> > and/or update() is the right solution for control messages.
> 
> These are control messages from the application, not from the server. And
Yes, that's what I meant. update() and message events are used to exchange
information with a server, but these control messages don't fit that model.

> these are specifically control messages which should require user
> interaction.


> > > Some examples of #2 are:
> > > - clear all cached state
> > Can you give an example where the application would need to do this?
> > Couldn't it just release() the sessions it knows about?
> 
> Yes. If the user is on a public computer and wants to clear any cached state
> before leaving. Releasing the sessions will not necessarily clear cached
> data. 
This data should be clearable via browser UI that enables clearing of other
such data:
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#privacy-storedinfo

> > > - domain leave requests, where the domain being left is selected by the web
> > > application
> > Can you provide more details? (Again, probably in a separate thread.) Why
> > doesn't release() work?
> 
> This is related to cacheing. It may be costly to join a domain (in terms of
> user  time and/or effort). Therefore it makes sense to cache the results
> once you have done it. It does not make sense to throw that work away just
> because the user has left the page or closed the browser. 

As I understand it, you want to control the lifetime of a persistent license
(even though it is not a content license). In theory, MediaKeySession provides
this. As noted elsewhere, I'm not sure why you would want to tie (or piggyback)
the two types of licenses together.

> > > It is desirable to be able to perform some of these operations prior to
> > > actually playing content, for example while the user is selecting a movie,
> > > in order to reduce the time to starting playback. However since the actions
> > > being requested may require network communications, it may make more sense
> > > to hang this additional parameter off of the createSession() call instead of
> > > the constructor to avoid adding another call/response channel directly to
> > > the MediaKeys.
> > What specifically is missing? We have release() (and the ability to respond
> > with messages) and loadSession(), so is it the creation that's a problem?
> 
> I was responding to the extra parameter being on the constructor, rather
> than on the createSession() call itself. The constructor may be called prior
> to any content being downloaded, so a key session may not be created. Since
> for some of my uses cases, I need network communications, I need a key
> session. Am I mistaken? I think with an extra parameter in both cases we are
> covered.
I think the root of the issue is that you want to create sessions or exchange
messages that are not related to any particular stream or content key ("for
example while the user is selecting a movie", "prior to any content being
downloaded") whereas the EME APIs have been designed around license exchanges
for specific keys (based on Initialization Data). Adding an extra parameter
(after |initData|) doesn't seem to solve the underlying issue.

> > > I would imagine performing a domain join using this mechanism to look
> > > something like this:
> > > 
> > > var extra = { 'action':'join', 'domain':'Lambda Lambda Lambda' }
> > > var mediaKeys = new MediaKeys("com.example.cdm");
> > > video.setMediaKeys(mediaKeys);
> > > var session = mediaKeys.createSession("video/mp4", initData, extras);
> > Do you really want to combine a domain join request with the processing of
> > meta data? Aren't these two separate operations, possibly with separate
> > "sessions".
> 
> In our case the information about the domain to be joined is carried in the
> metadata.
I'm not sure what metadata you're referring to. Is it something in the
Initialization Data (|initData|) or |extras|? If the former, is this metadata
[in] a PSSH or something else?

> So it must be processed at the same time. That metadata may be
> entirely independent of a content stream however. 
Then why would it be combined with the license exchange for a particular stream
(|initData|)? Or are you proposing that |initData| is not actually
Initialization Data.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 4 March 2014 01:08:14 UTC