v0.1 says that MEDIA_KEYERR_CLIENT means "The Key System could not be installed or updated."  Is there a reason that applications might need to differentiate between the install and update cases?
Is there a third case for "could not be loaded" or something similar? If so, we should either add this text or consider another error.
Assigned to Adrian to follow-up with MSFT team on how to use this error.
There is a reason applications might want to differentiate between the install and update cases. In the update case, the application may be able to access alternate content of lesser value that does not require an updated CDM. With the ability to distinguish between these two cases, the application can make the choice.
There might be other "client" errors, such as the CDM is disabled or failed to load. Those seem different from not being able to install or update the CDM. This could fall under MEDIA_KEYERR_CLIENT (with a modified description), but if we break that up, we may need more for disabled or failed case(s).
Separately, what does install/update mean in practice? CDMs won't be installed in response to createSession(), right?
> Separately, what does install/update mean in practice? CDMs won't be
> installed in response to createSession(), right?
I think that loading/installing of CDMs should be allowed. Given that, createSession() would be a reasonable time to do it, since the app has indicated a clear intention to use it. This seems like the first time that is true.
Re: differentiating between install and update --
If the keysystem name is used to track versions of the keysystem (as seemed to be the original intent) distinction is possible by leveraging that mechanism. Are we still intending for keysystem to be used that way?
So an app could ask for com.adobe.access.v5 and if it gets back MEDIA_KEYERR_CLIENT, it can then ask for com.adobe.access.v4, com.adobe.access.v3, etc. That seems reasonable to me.
We will address this as part of bug 21798.
*** This bug has been marked as a duplicate of bug 21798 ***