- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 4 Jun 2015 07:20:23 +0000
- To: Dan Burnett <dburnett@voxeo.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
No one objected, so the conclusion is that the editors will incorporate Dan's proposal (as outlined further below). Stefan for the chairs On 29/05/15 08:46, Stefan Håkansson LK wrote: > Note: the definition of Errors is something we have been struggling > with. Dan has now (after discussing with people) developed a > proposal, see below. > > The proposal was sent Tuesday this week, unless we hear objections > by Tuesday next week we will ask the editors to incorporate the > proposal in the Media Capture and Streams document. > > Stefan for the chairs. > > > On 26/05/15 15:11, Dan Burnett wrote: >> I have been tasked with providing a proposal for how to proceed to >> address issue #162 [1]. >> >> Based on a conversation among Domenic Denicola, Jan-Ivar, and >> others in PR #170 [2] (which was merely a draft of how to add a new >> error using ECMAScript 6-style language), I suggest the >> MediaStreamError defined in the Media Capture and Streams >> specification be removed and the errors in section 7.2 be addressed >> as follows. >> >> The following DOMException errors already defined in WebIDL will >> use their WebIDL names: - AbortError - NotSupportedError - >> NotFoundError >> >> The following errors that are new but semantically similar to >> existing error names will use those names, as suggested by Domenic >> Denicola in the above PR: - PermissionDeniedError will be replaced >> with the DOMException SecurityError - SourceUnavailableError will >> be replaced with the DOMException NotReadableError >> >> The two errors OverconstrainedError and ConstraintNotSatisfiedError >> will be combined into one new OverconstrainedError to be defined >> using EMCAScript 6-style language and include a new property >> 'constraint' to hold the name of a mandatory constraint that is >> overconstrained/not satisfied. It is not possible to use WebIDL >> here (see the PR conversation), so the ES6 definition is the way we >> would need to proceed. >> >> >> Does anyone on the list have objections to this approach that they >> would like to discuss? If not, I will write up the pull request >> making these changes. >> >> Any remaining events, if any, that could be generated based on the >> new set of errors (beyond the asynchronous returns already >> addressed by Promises) would require at least one additional pull >> request after this one to spec out. >> >> -- dan >> >> [1] https://github.com/w3c/mediacapture-main/issues/162 [2] >> https://github.com/w3c/mediacapture-main/pull/170 >> > > >
Received on Thursday, 4 June 2015 07:20:51 UTC