Re: WebMidi

On Thu, Dec 20, 2012 at 9:27 AM, Marcos Caceres <w3c@marcosc.com> wrote:

> On Thursday, December 20, 2012 at 5:21 PM, Brian Kardell wrote:
> > > > This is exactly the part of the discussion that i think is worth
> having. If you xRequest - do you get MIDIEvent or xMIDIEvent... If you get
> the later, then what you describe is not so much a problem, right?
>

In general practice, I would expect for prefixing purposes we would prefix
the top-level entry point, but not the sub-points - i.e.,

webkitRequestMIDIAccess();

but

MIDIInput.onmessage = function(e) {};

That's both common practice (e.g. in Web Audio) and it makes it much, much
easier to both switch over in the codebase, and switch code over (presuming
few changes from the original implementation).

> 1) how we'd make Chris' WebMIDIAPI[2] fit the discussion above to be a
> prollyfill according to the definitions I think we've agreed to. It seems
> to me that according to the draft, most of it is available through the
> navigator object via navigator.requestMIDIAccess.
>


> I think Chris' solution is serving as a "reference implementation" for the
> Web MIDI API (this is distinctly different to a prollyfill or polyfill). As
> such, it's in a difficult position in that it has to primarily serve the
> needs of the Web Audio Working Group: the needs are mainly to do with
> sanity checking the usability and implementability of the API, and enabling
> verification of tests when the group starts doing conformance testing.
>

Indeed, "reference implementation in Javascript, based on a plugin" is
probably a better description for how I think about it; however, I also see
this code as useful as a way to add the support that's not there in current
browsers (Chrome included).

Of course, if you're building a production app pointing to my .js file on
my server, and you expect that to continue to work day-to-day as the spec
evolves, I can tell you right now... "you're gonna have a bad
time.<http://youtu.be/Zypvv8ig_7s>
"


> So, I would not be in favor in asking Chris to change his implementation.
>
> However, my own version of the API (which does not follow the spec) is
> more in line with a prollyfill. I'd be happy to change mine to become a
> prollyfill proper.
>

I'm fine with someone else doing this (a prefixed version), or even
maintaining a branch/fork that way myself; but I do want to have one that
just says "do what the current spec says, include this .js, and your code
should work."

-C