[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] RE: extension development process

I don't think it's a problem not to define the how to do it at this time. As long as there's agreement that that kind of extension does not fit into the existing process we have.

On Wed, Feb 11, 2015 at 2:10 PM, Florian Bösch <pyalot@gmail.com> wrote:
It would be confusing because then it becomes impossible for users to gauge the safety and future-proofness of using an extension based on its status.

On Wed, Feb 11, 2015 at 2:09 PM, Florian Bösch <pyalot@gmail.com> wrote:
If you don't have a way to deal with non standard extensions, then the status of proposal, draft and community approved become meaningless and should be abandoned. Because the result would be that extensions which are consensus based and multi-vendor implementation based find themselves in "community approved" alongside extensions which aren't. That would be quite confusing.

On Wed, Feb 11, 2015 at 1:56 PM, Florian Bösch <pyalot@gmail.com> wrote:
OpenGL and OpenGL ES has a clear scheme to deal with non-standard extensions. They're vendor prefixed. They don't have publicly transparent scheme for proposal/draft/community approved/ratified states (although some of that is noted on the extensions).

WebGL lacks a clear scheme to deal with non-standard extensions, and so we're having discussions about the deeper meanings of the standards track states. Adding a non-standard category allows the standard categories to be rigid and easy to follow. Not allowing a non-standard category makes it muddy and uncertain what these "standard track" categories even mean.

On Wed, Feb 11, 2015 at 1:38 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell <kbr@google.com> wrote:
In my opinion, adding an extension proposal for a vendor's particular
extension idea is a viable option.

It's not a viable option. In order to publicly expose an extension it has to move to "Community Approved". In order to do that, consensus has to reached on the proposal, and multiple vendors have to be implementing it. It's a good option for an extension for which that process is intended, and it should if at all possible be intended for every extension. But it could happen that that's not the case (for instance there could be proprietary IP attached to the extension, or no consensus could be reached, or unsurmountable implementation difficulties could emerge etc.), but the vendor would still like to expose the extension. Moving something to "Community Approved" that isn't is perverse.