[Bug 24025] Add optional configuration parameter to MediaKeys constructor

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

--- Comment #11 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #10)
> 2) Add a "persistent" attribute to MediaKeys.
> When true, the CDM will persist created sessions and load sessions from
> persistent storage. When false, things work as they do today (and
> loadSession() throws an exception). If a UA or key system implementation
> does not support persisting licenses, the UA may throw a NOT_SUPPORTED_ERR
> when an application attempts to set "mediaKeys.persistent = true".

I don't think this attribute makes sense. Either there is a significant
performance benefit to setting this flag and it will always be set by the
application, or there is not and caching will be determined by license policy.
Do you have a use case where this attribute would be determined by something
other than the key system selected?

In the spirit of adding explicit extensions, I would like to add a fourth
category. 

4) Add an optional "license domain" to MediaKeys. 
This would allow the application to select the license domain against which
keys should be requested. There may be multiple domains (potentially requiring
user selection) and the CDM will not have the policy logic to make this
decision. I am not sure whether in all cases this could be deferred to a server
communication either, since it may required user interaction. This is something
the application has to be able to handle. 

I am also having a problem with this bit from the original request:
> Note that this parameter is intended to be used for configuring the 
> key system and *not* to provide data from the application to be sent 
> as part of message event(s)."

This feature should be targeted at exactly what this line says it is not - i.e.
providing data from the application to be sent (or used) as part of the message
events. Server certificate certainly falls into that category.

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

Received on Wednesday, 12 March 2014 16:51:31 UTC