Re: Web MIDI polyfill

Happy face :-)

Mohamed


On Thu, Dec 13, 2012 at 6:07 PM, Marcos Caceres <w3c@marcosc.com> wrote:

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


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