Re: Note regarding Proposal for issue #162: 'MediaStreamError should not be an interface'

To be clear, I will now be creating a pull request with specific text.  That is then available for anyone to review as usual.

-- dan

On Jun 4, 2015, at 3:20 AM, Stefan Håkansson LK wrote:

> 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 14:20:05 UTC