Re: Web MIDI polyfill

On Thu, Dec 13, 2012 at 11:06 AM, Clint Hill <clint.hill@gmail.com> wrote:

> I have to agree with François on this. I dislike the idea of a prollyfill
> depending on a plugin. Flash was a very hard lesson (speaking from work
> experience) for many devs and it was nearly ubiquitous. And don't we all
> remember ActiveX? :)
>
>
> On Dec 13, 2012, at 3:32 AM, François REMY <francois.remy.dev@outlook.com>
> wrote:
>
> Building on tops of browser plugins is a nice way to make prototypes but
> this is not a prolyfill in the sense that:
>
> - it’s not immediate (the user will see a broken page the first time and
> will be asked to download a plugin)
> - it’s not cross-platform (no plugin works on iOS and Windows Phone for
> example)
> - it’s not forward compatible (the plugin may break, or not exist for
> newly popular platforms)
>
> This is what the Flash experience reminds us: at some point Flash was
> installed on 95% of the computers and using Flash to make prolyfills was
> widely used (async file uploads, animations...). Now, Flash is not
> available on most mobile platforms and the sites relying on Flash face
> issues. This is not the kind of model we want to promote in next-web.
>
> I still believe we have to believe in our JavaScript-based prolyfill
> model, which is the only one that can truly be forward compatible.
> JavaScript is turing complete so there must be another way to support MIDI
> playback (for exemple converting the MIDI file into a MP3 on the go by
> transcripting the plugin using Emscripten).
>
> Nice achievement anyway ;-)
> François
>
>
>
>
> *De :* Brian Kardell
> *Envoyé :* 13 décembre 2012 06:47
> *À :* Innovimax W3C
> *Cc :* public-nextweb@w3.org
> *Objet :* Re: Web MIDI polyfill
> On Wed, Dec 12, 2012 at 12:04 PM, Innovimax W3C <innovimax+w3c@gmail.com>
> wrote:
>
>>
>> Forwarded with permission from Chris Wilson
>>
>> FYI
>>
>> Mohamed
>>
>> ---------- Forwarded message ----------
>> From: Chris Wilson <cwilso@google.com>
>> Date: Tue, Dec 11, 2012 at 2:13 AM
>> Subject: Web MIDI polyfill
>> To: "public-audio@w3.org" <public-audio@w3.org>
>>
>>
>> I just wanted to let the group know that I've now also updated my Web
>> MIDI API polyfill (https://github.com/cwilso/WebMIDIAPIShim), which
>> builds on top of the Jazz-soft.net NPAPI plugin to add Web MIDI API
>> support on OSX and Windows (if you install the Jazz plugin v1.2 or later).
>>
>> The polyfill uses the current syntax of the API in the specification; I
>> also added multiple simultaneous I/O support (the polyfill could previously
>> only support one input and one output at a time), sending and receiving
>> long messages (system exclusive), support for timestamps (on send and
>> receive), albeit of course with only setTimeout-level precision (it is a
>> JavaScript polyfill, after all), and (I think) proper event dispatching
>> (i.e. you can use addEventListener as well as onmessage).
>>
>> In short - you should be able to include this polyfill in a project, and
>> it will add Web MIDI support to your browser.  (Caveat: have not thoroughly
>> tested the cross-browser implementation; I know CustomEvent is not there on
>> IE<10, which would be an issue.)
>>
>> Happy to take further suggestions.
>>
>> -Chris
>>
>>
>>
>> --
>> Innovimax SARL
>> Consulting, Training & XML Development
>> 9, impasse des Orteaux
>> 75020 Paris
>> Tel : +33 9 52 475787
>> Fax : +33 1 4356 1746
>> http://www.innovimax.fr
>> RCS Paris 488.018.631
>> SARL au capital de 10.000 €
>>
>
>
> Aside from the fact that this uses a plugin this is an excellent example
> of what I had in mind IMO.  After looking at it though and talking to some
> people -- I don't think that it uses a plugin really makes it problematic
> as a prollyfill or anything, so maybe I was thinking too narrow
> originally... I mean, adopting that strategy actually makes it more
> practical to fill a whole lot more things.
>
> Thoughts?
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>
>
>

OK, leaving aside the ecmascripten idea for a minute... Let me explain why
I eventually changed my mind on this "in general" and not specifically
related to whether or not this particular one should or shouldn't be (I
think that is a somewhat separate question): What is the purpose of a
prollyfill? In my mind, it serves many purposes - but the primary one is
that it allows us to have an implementation along with a draft proposal
which both helps flesh out the proposal and actually lets people try to use
the APIs, maybe even fork and compete - so that early on we can easily
iterate and things aren't likely to break if we need to change the API
because the author opts in.  A huge benefit to this is that it means that
many of these can be used _practically_ not just experimentally and get a
whole more eyeballs and users as they get popular.

However - there is a known problem that a great many things are simply
unprollyfillable - this may actually be one or not - leave that aside for a
moment - because it is a low level API requiring capabilities or
permissions we do not currently have.  Losing the ability to prollyfill in
that area is, to my mind, a _very great_ loss.

Now, what are the implications?  The implications are that it doesn't work
on certain kinds of browsers and not without permission of the viewer.
 Actually - that's a lot like the prefixed "mavens" model we have now -
it's not cut to the whole world, but just a segment of willing people who
want to test/play/improve/etc... If I step back and look at it honestly -
it seems better than the prefixing model that we currently have IMO because
you fill at least of great swath of them at once and it's not tied to a
single browser, should be relatively forward compatible...  An ideal case
might be that things at that level start out that way and serve as
proof/fire to get those low level APIs in there -- that would free up the
work hours of all of the implementers to do things we really need them to
do with great efficiency, focus and speed :)

As I said at the outset - one thing that is inevitably going to be
necessary for us is some sort of compatibility chart like you see on
caniuse or something... It seems to me that as long as they are clearly
flagged that way - this could actually work pretty well.

Another thing I think we would want realize is that we want to encourage
competition and review... Francois came up with an interesting idea - I
think if we could see it and it was performant enough, not a trillion lines
of code and required no plugins - that is clearly what I'd endorse... you
know?  And honestly, Chris Wilson might too because who wants to rely on a
plugin if  you don't have to.


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