W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Web MIDI] Review of getMIDIAccess algorithm

From: Marcos Caceres <w3c@marcosc.com>
Date: Thu, 13 Dec 2012 14:13:07 +0000
To: public-audio@w3.org
Message-ID: <37D59C321D0C49FDBD9F18AACB0FEF3C@marcosc.com>
This is a review of the getMIDIAccess algorithm. I've copied the text from the spec and made comments on each line.  

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. 
Received on Thursday, 13 December 2012 14:13:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC