[Bug 20376] New: Terminology feedback

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20376

            Bug ID: 20376
           Summary: Terminology feedback
    Classification: Unclassified
           Product: AudioWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: MIDI API
          Assignee: dave.null@w3.org
          Reporter: jussi.kalliokoski@gmail.com
        QA Contact: public-audio@w3.org

On Thursday, December 13, 2012 at 1:53 PM, Marcos Caceres wrote:
> Obtains an interface to enumerate and request access to MIDI devices on the user's system.
>
> This call may prompt the user for access to MIDI devices.
The above needs to be a SHOULD.
> If the user accepts

accepts should be "If the user gives express permission"
> or the call is otherwise approved, successCallback is invoked, with a MIDIAccess object as its argument.

>
> If the user declines or the call is denied, the errorCallback (if any) is invoked.
All the above should really be in the algorithm or all this should be labelled
as non-normative (i.e., this is a note of how it works conceptually, but can't
be implemented).

> When the getMIDIAccess() method is called, the user agent must run the following steps:
>
> Let successCallback be the callback indicated by the method's first argument.
>
> Let errorCallback be the callback indicated by the method's second argument, if any, or null otherwise.
I think it' redundant for NavigatorMIDIAccessErrorCallback to be nullable when
it's already optional.
> If successCallback is null, abort these steps.

This is wrong. Error handling is handled by WebIDL. Having this here conflicts
with WebIDL's behavior.
> Return, and run the following steps asynchronously.
>
> Optionally, e.g. based on a previously-established user preference, for security reasons, or due to platform limitations, jump to the step labeled failure below.
>
> Optionally, e.g. based on a previously-established user preference, jump to the step labeled success below.
>
> Prompt the user in a user-agent-specific manner for permission to provide the entry script's origin with a MIDIAccess object representing control over user's MIDI devices.
>
> If permission is denied, jump to the step labeled failure below. If the user never responds, this algorithm stalls on this step.
>
> success: Let access be the MIDIAccess object for which access has been granted.
>
> Queue a task to invoke successCallback with access as its argument, and return.
>
> Failure: If errorCallback is null, abort these steps.
Better would be to say, "if errorCallback is a callable". WebIDL would have
caught other types already.

> Let error be a new NavigatorMIDIAccessError object whose code attribute has the numeric value 1 (PERMISSION_DENIED ).
Change this to DOMError (this is either a "securityError" or
"NotSupportedError" depending on situation). Please don't introduce new Error
types into the platform.

I have another email about this… but basically, you don't need
NavigatorMIDIAccessError. Please delete it.
> Queue a task to invoke errorCallback with error as its argument.
>
> The task source for these tasks is the user interaction task source.
>
Above seems ok.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 13 December 2012 15:08:02 UTC