- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Jan 2016 20:38:07 +0000
- To: public-html-media@w3.org
ddorwin has just created a new issue for https://github.com/w3c/encrypted-media: == Gracefully handling implementations that do not support setServerCertificate() == As noted in the algorithm, Key Systems and specific CDM implementations may not support server certificates or providing them via [`setServerCertificate()`](https://w3c.github.io/encrypted-media/#setServerCertificate). For such implementations, the spec says to reject the promise with `NotSupportedError`. An application that uses this method but does not explicitly handle `NotSupportedError` could unnecessarily fail when run on such implementations. One option is to add a Note explicitly noting that applications should gracefully handle a rejection with `NotSupportedError` (while still seeing other rejections as unexpected failures). However, that seems like a strange requirement to place on applications when not supporting this method is allowed _and_ this "failure" does not negatively affect the rest of the application. (In other words, there is no exceptional behavior that needs to be executed.) Alternatively, we could change the algorithm to resolve (while indicating that that the call did not actually do anything). This seems more consistent with https://www.w3.org/2001/tag/doc/promises-guide#rejections-should-be-exceptional. (This was the same principle that resulted in [`load()`](https://w3c.github.io/encrypted-media/#load) of an unrecognized session resolving with `false`. Therefore, I propose changing `setServerCertificate()` to return a `Promise<boolean>` where the Boolean is `true` on success (current step 6) and `false` when the CDM does not support the operation (current step 2). Please view or discuss this issue at https://github.com/w3c/encrypted-media/issues/145 using your GitHub account
Received on Thursday, 28 January 2016 20:38:09 UTC