Re: WebMidi

On Thu, Dec 20, 2012 at 1:20 PM, Chris Wilson <cwilso@google.com> wrote:

> 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).
>

Yeah I think that makes sense in this case -- where it gets kind of weird
is when you have established objects with new methods/properties proposed.


>
> > 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
>



Yeah for a prollyfill to work, we need a fork with versioned draft/impl...
fork or branch might work - but worst case, I think maybe you could just
link to it in your readme or something with the same kind of "you're gonna
have a bad time" note.

-- 
Brian Kardell :: @briankardell :: hitchjs.com