requestMIDIAccess should vend a Future, and not direct callbacks

[cwilso]

As per Alex and Anne's feedback (http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0176.html):

requestMidiAccess can (should?) be re-worked to vend a Future. A cleaned up
interface for it might be:

partial interface Navigator {
    Future requestMIDIAccess (optional boolean systemExclusiveSupportRequested = false );
};

[toyoshim]

Is there already an API to use 'Future' in HTML5?
I can not find it, but the term 'Future' is very difficult to search :(

Anyway, in this case, I prefer to pass arguments as a dictionary like File API.

e.g.,

directory Flags {
    boolean systemExclusive;
};
partial interface Navigator {
    Future requestMIDIAccess (optional Flags request);
};

Currently, there is another concern about MIDIPort.id as issue 48; #48 . If we should disguise MIDIPort attributes, name, manufacturer, and so on, we may want to add some arguments here to get raw attributes. e,g,

directory Flags {
    boolean systemExclusive;
    boolean portName;
    boolean portManufacturer;
};

[marcoscaceres]

@toyoshim Futures are defined here: http://dom.spec.whatwg.org/#futures

[cwilso]

As I've not actually USED futures before, I wanted to try to see how this would work. I understand the value and use of futures in the abstract sense in more complex async programming, I think, but I'm quite concerned about the usage of futures here keeping MIDI implementation held back until futures are broadly implemented (and understood by developers), unless there's a solid reason for using them. I can't tell if this just "we should do all things in this model from now on."

I think the usage of this would look like:

requestMIDIAccess( sysexFlag ).done( successFunc, failFunc );

But I don't see a ton of value (and I do see added complexity) over

requestMIDIAccess( successFunc, failFunc, sysexFlag );

In a situation where multiple async calls are in play, and there are multiple lifetimes of asynchronous calls that overlap (and interleave) in potentially "interesting" ways, I see the value of the futures pattern. With Web MIDI, the requestMIDIAccess call is asynchronous purely to enable user prompting; and requestMIDIAccess is likely called once, on loading of the page, and the object obtained is kept for the lifetime of the page.

Can someone enlighten me? Marcos, Anne, Alex?

[jussi-kalliokoski]

I see added value and reduced complexity in just the reduced number of arguments required for requestMIDIAccess. :) As small part of the complexity is defined in our spec, the happier I feel about it.

That said, I'd like to know whether there is a common plan to normalize asynchronous APIs to use Futures. If that's not the case, let's not jump into this, but if it is, SGTM.

[cwilso]

This doesn't really "reduce complexity". The same parameters need to be
documented, and it makes the usage considerably less clear (until such time
as, presumably, Futures become so common that it's intuitive).

I've dug into this with Alex a bit more; there is certainly a large
contingent who are pushing for Futures as a common normalization of async
APIs. I'm still a bit skeptical, but thinking it through.

On Sun, Apr 28, 2013 at 9:49 AM, Jussi Kalliokoski <[email protected]

wrote:

I see added value and reduced complexity in just the reduced number of
arguments required for requestMIDIAccess. :) As small part of the
complexity is defined in our spec, the happier I feel about it.

That said, I'd like to know whether there is a common plan to normalize
asynchronous APIs to use Futures. If that's not the case, let's not jump
into this, but if it is, SGTM.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-17137239
.

[marcoscaceres]

I'm happy with either, fwiw.

[jussi-kalliokoski]

In a situation where multiple async calls are in play, and there are multiple lifetimes of asynchronous calls that overlap (and interleave) in potentially "interesting" ways, I see the value of the futures pattern. With Web MIDI, the requestMIDIAccess call is asynchronous purely to enable user prompting; and requestMIDIAccess is likely called once, on loading of the page, and the object obtained is kept for the lifetime of the page.

Actually, the thing is that we can't anticipate how the API will be used together with other APIs, and I doubt that there won't be cases where the MIDI access request runs in parallel with other asynchronous operations so I believe going with something that offers consistence for asynchronous operations definitely has value.

I'm leaning towards vending a future. :)

[cwilso]

I definitely want to vend a future, the question I have remaining is
whether we should have rMA take optional success/fail callbacks as well, to
simplify the pattern for developers who haven't even heard of futures
(currently most).

On Wed, May 1, 2013 at 10:25 AM, Jussi Kalliokoski <[email protected]

wrote:

In a situation where multiple async calls are in play, and there are
multiple lifetimes of asynchronous calls that overlap (and interleave) in
potentially "interesting" ways, I see the value of the futures pattern.
With Web MIDI, the requestMIDIAccess call is asynchronous purely to enable
user prompting; and requestMIDIAccess is likely called once, on loading of
the page, and the object obtained is kept for the lifetime of the page.

Actually, the thing is that we can't anticipate how the API will be used
together with other APIs, and I doubt that there won't be cases where the
MIDI access request runs in parallel with other asynchronous operations so
I believe going with something that offers consistence for asynchronous
operations definitely has value.

I'm leaning towards vending a future. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-17293373
.

[jussi-kalliokoski]

I definitely want to vend a future, the question I have remaining is whether we should have rMA take optional success/fail callbacks as well, to simplify the pattern for developers who haven't even heard of futures (currently most).

Maybe. But generally speaking, I think giving developers many ways to do the same thing probably won't avoid confusion, quite the contrary. :)

[cwilso]

Developers don't read the IDL. They read the sample code. :)

On Wed, May 1, 2013 at 10:36 AM, Jussi Kalliokoski <[email protected]

wrote:

I definitely want to vend a future, the question I have remaining is
whether we should have rMA take optional success/fail callbacks as well, to
simplify the pattern for developers who haven't even heard of futures
(currently most).

Maybe. But generally speaking, I giving developers many ways to do the
same thing probably won't avoid confusion, quite the contrary. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-17294081
.

[jussi-kalliokoski]

Developers don't read the IDL. They read the sample code. :)

Then why bother adding a redundant & non-recommended way of doing things?

[cwilso]

OK, well - my co-editor says change to futures, no one else has complained
about it: futures only it is.

On Wed, May 1, 2013 at 10:43 AM, Jussi Kalliokoski <[email protected]

wrote:

Developers don't read the IDL. They read the sample code. :)

Then why bother adding a redundant & non-recommended way of doing things?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-17294515
.

[cwilso]

IDL:
Future requestMIDIAccess(optional dictionary? options)

Usage:

requestMIDIAccess().done( success, failure );
or
requestMIDIAccess( sysexRequired ).done( success, failure );

[jussi-kalliokoski]

Great!

requestMIDIAccess( sysexRequired ).done( success, failure );

Do dictionaries work like this (I assume you meant sysexRequired to be a boolean)? I thought it would be either:

requestMIDIAccess( 'sysexRequired' ).done( success, failure );

or

requestMIDIAccess( { sysexRequired: true } ).done( success, failure );

[marcoscaceres]

Work like the second one.

[jussi-kalliokoski]

Work like the second one.

The first one doesn't work at all? Good to know, I saw it in the old getUserMedia examples, like getUserMedia('audio', ...) and thought it worked like that. But I'm actually happy that it doesn't work like that. :P

[cwilso]

getUserMedia used to (in Chrome?) work differently, and not follow the
current spec.

On Wed, May 1, 2013 at 11:10 AM, Jussi Kalliokoski <[email protected]

wrote:

Work like the second one.

The first one doesn't work at all? Good to know, I saw it in the old
getUserMedia examples, like getUserMedia('audio', ...) and thought it
worked like that. But I'm actually happy that it doesn't work like that. :P

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-17296631
.

[marcoscaceres]

@jussi-kalliokoski yeah, that shouldn't work... that's pretty ugly if it does. I like the use of the option as it makes the code easy to understand.... and you can do { sysexRequired: "hell yeah!" } if you are feeling kinda badass.

[cwilso]

Fixed: 78ae07b.

[jussi-kalliokoski]

LGTM, aside from the slip there. \o/