Re: Web MIDI polyfill

I like your definitions with exception to one point: You say "draft" in both definitions and I think that for Prollyfill there are large opportunities for un-drafted ideas. The goal of a Prollyfill is to get a draft in some cases. On the other hand Polyfills are coded to a draft/rec.

I tried to delineate on that idea: http://clint-hill.com/2012/12/03/extending-the-web/

In my opinion that's an important separation to make.


On Dec 13, 2012, at 8:02 PM, Brian Kardell <bkardell@gmail.com> wrote:

> 
> 
> 
> On Thu, Dec 13, 2012 at 7:04 PM, François REMY <francois.remy.dev@outlook.com> wrote:
> The following point is included in our scope statement:
> 
>    • Get the concept of “forward polyfill” known by the other W3C
>       groups and encourage spec editors to create prototypes for their
>       drafts *using prolyfils*.
> 
> I therefore propose we drop the *using prolyfills* part and split that into
> two separate goals:
> 
>    • Get the concept of “forward polyfill” known by the other WGs
>    • Encourage spec editors to create prototypes for their drafts
> 
> I support that - I would like to add a bullet about something like "create a community of peer review, discovery and common efforts" and include in the second bullet above something like "and help define and advocate a lifecycle from idea to standard" 
> 
>  
> I also agree that we should maybe explain what we mean by
> the following keywords in our scope statement, as thet may seem
> identical to newcomers :
> 
> polyfill - prolyfill - shim 
> 
> 
> I think that I have blogged and written about this before... Pollyfill and shim were terms coined with definitions by Remy Sharp.  Here is my best definition, feel free to pick them apart, improve them or debate... Moving in order from "closest to actual standard" to merely "some API":
> 
> - polyfill:  something which provides implementations for a stable and mature draft or recommendation which is lacking native implementation in one or more currently popular browser, but has native implementations (sometimes while they are still prefixed, but not behind a flag).  Usually, they use a simple "use the native unless it is not there" approach, so your site can automatically upgrade to native as it becomes available.
> 
> - prollyfill:  something which provides implementation of a draft as the draft matures and allows us to suss it out, pick it apart, provides alternatives and decide what to natively implement.  Its intent is to become a standard, it is tied to no particular browser implementation (though it might only work in "modern browsers" in the current ecosystem - it should work in all modern browsers), it is opted in by the author and bound to an implementation version which tracks to the spec - so it won't ever "break" (at least not for any rational reason) despite the fact that the draft might evolve quite a bit.
> 
> - shim:  something which provides an alternative API to a mature API (even a REC with wide implementation in modern browsers) in older browsers for the sake of (usually rough) capability parity.  <-- NOTE: I don't think we should concern ourselves with these... They have no draft an are actually only a rough hop from the next bullet...
> 
> - libraries:  Just new API implementations with no draft and no intent to become a standard, etc... These can be pretty micro and focused, but more often than not they generally mix a lot of useful APIs into an attempt to make it generally easier to complete (usually) common use-cases in Web development. <--- NOTE:  I also don't think we should concern ourselves with these.
> 
> 
> 
> 
> 
> -- 
> Brian Kardell :: @briankardell :: hitchjs.com