Re: Web MIDI polyfill

On Thursday, December 13, 2012 at 4:31 PM, Brian Kardell wrote:

>  
> 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.
This is exactly what I've just being doing. I took Chris' code and rewrote it and found a ton of bugs in the spec. I've been bombarding the Web Audio guys with comments on what to change and the spec has already changed significantly since yesterday.  

see:

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20364
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20376


>  
> 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.
Absolutely! Having the plugin also allows prototyping of a secure UI. See https://twitter.com/marcosc/status/279264665639481344/photo/1  
>  
>  
> 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.  
It's actually worst with plugins… like this midi one gives you access to anything with no questions asked :)   
> 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.
Not following this bit…   
>  
>  
> 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.
That's the ultimate goal, obviously. But it's been really helpful to prototype stuff (made a massive difference in the last 12 hours).

Received on Thursday, 13 December 2012 17:08:24 UTC