- From: <bugzilla@jessica.w3.org>
- Date: Fri, 31 Oct 2014 15:18:18 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26776 --- Comment #9 from Jerry Smith <jdsmith@microsoft.com> --- Error options currently implemented in EME or being discussed are: - DOMExceptions using standard error names for specific violations of method requirements - Key Status events (https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372) with standard types for error states encountered outside of executing a specific EME method. I believe these types are still proposed: o "acquired", o "expired", o "notyetvalid", o "renewalfailed", o "playbacksexceeded", o "authorizationfailed", o "outputnotallowed", o "downscaling", o "released" Of these two mechanisms, the key status message most closely aligns with the requested delivery of systemCode error details. The primary goal for systemCode support is to allow CDM specific error states to be reported, tracked and resolved. Standard classifications are very useful, but so is the ability to isolate CDM specific problems. I’d like to see two specific changes to key status events to resolve this bug: 1. Include a classification for other CDM specific errors 2. Include an optional systemCode to provide more information on the CDM specific error An alternative to this would be to revisit using DOMExceptions more broadly for CDM specific errors, and encode the numeric codes as strings in the optional message attribute. We have concluded this could be workable, but I am not sure it is appropriate to fire DOMExceptions for CDM execution errors not associated with a specific API call. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 31 October 2014 15:18:19 UTC