Re: [EME] Persistent license

Trimmed a bit for readability — 

Joe

On Apr 4, 2014, at 1:26 PM, David Dorwin <ddorwin@google.com> wrote:

>> 2) Performance penalty
>> Even if we have a fixed rule of #1 above, it requires CDM to look through all the persisted sessionId each time createSession is called
> 
> I agree. 
> 
> I don't understand. How does loadSession() impact createSession() in this way? If anything, using loadSession() to load persisted sessions avoids performance penalties that may occur if createSession() is allowed to load persisted sessions.

The impact I am thinking of relates to my parallel thread about sessions containing non-content keys. Since the application does not in general know about non-content keys, it cannot know in general what sessions need to be passed to loadSession() in order to satisfy a key requirement. The CDM however has complete knowledge about cached keys and can load only the appropriate keys. 

>> 4) Optional loadSession is dependent on user agent implementation
>> If loadSession is not supported in a user agent, we can’t support persisted license in the user agent even though CDM supports it.
>> If we allow createSession (or new mandatory explicit method) to load persisted license, whether to support persisting license is up to CDM implementation.
> 
> User agents are ultimately responsible for what is exposed to the web platform and ensuring security and privacy. They are also responsible for vetting the key systems (CDMs) they expose and deciding what features to expose. Whether loadSession() is mandatory or not does not affect this.
> 
> Nothing actually says loadSession() is optional. The method must exist. However, a user agent could choose to only execute step 1.
> 
> I agree. I don’t see the benefit loadSession provides over createSession.
> 
> Applications will see a consistent and expected behavior. They will know when data is being loaded and when a new session is being created. This goes hand in hand with being explicit about when data is persisted. If this is not explicit, applications won't know when they need to clear it. There is a real world issue right now with some implementations that is directly related to this issue. Also, separating the methods avoids potential performance issues in the non-persisted case.

Can you explain why this implementation issue would be satisfied by a loadSession() call but would not be equally satisfied by a loadKey call?

Also — can you explain what the performance issue is that you see in the non-persisted case? 

The only issue I see that could potentially require a loadSession call is the need to explicitly use persisted keys as opposed to allowing the CDM to request them from a server. Shinya mentioned this on another thread and we have seen this customer requirement as well. But I have only seen this as a firm need in the offline playback case which the group has basically said we will not support yet.