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

Re: [Public WebGL] RE: extension development process

I'll ilustrate the idea of the process (including a non-standard track) http://codeflow.org/pictures/extension-process.svg

On Wed, Feb 11, 2015 at 12:48 PM, Olli Etuaho <oetuaho@nvidia.com> wrote:

Yep, the extension registry also says that "Every extension should advance to Khronos ratified". It would be good to add a separate track for non-standard extensions that are not meant to be exposed to the public web if some vendor is interested in implementing such extensions. But I'd defer adding such a track until there's an actual use case for it.


From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Florian Bösch <pyalot@gmail.com>
Sent: Wednesday, February 11, 2015 1:35 PM
To: Kenneth Russell
Cc: Frank Olivier; Dean Jackson; public webgl
Subject: Re: [Public WebGL] RE: extension development process
Besides there's no reason the registry couldn't list NONSTANDARD_* extensions under a category "Non Standard Extensions".

On Wed, Feb 11, 2015 at 12:23 PM, Florian Bösch <pyalot@gmail.com> wrote:
That doesn't address the issue I see. Without a way for a vendor to expose nonstandard extensions to the public, they're required to submit it to proposal, get it to draft and push it trough to community approved before they can expose it to the public. In turn this means that any single vendor can demand that their extension is elevated practically straight to community approved without consensus at the proposal stage, without alternative implementations at the draft stage and without community approval at the community approved stage.

Effectively your suggestion amounts to that proposal, draft and community approved are "standards exempt". I do think that proposal, draft and community approved are standards track states.

On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell <kbr@google.com> wrote:
I think the WebGL extension registry should document all extensions,
even those which might not be intended for a standards track. It's not
a burden to write a little documentation for new extensions, and gives
other implementers the opportunity to provide some compatibility. It's
also not a big burden to leave an extension in draft status for some
time while its utility is being proven.

There was a long discussion about vendor prefixes for WebGL extensions
some time ago, with the conclusion that draft extensions should
preferably be exposed behind some sort of run-time flag, not enabled
by default, and also not use vendor prefixes. I've updated the
extension registry in https://github.com/KhronosGroup/WebGL/pull/861
to indicate this.


On Wed, Feb 11, 2015 at 7:50 AM, Florian Bösch <pyalot@gmail.com> wrote:
> On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier <Frank.Olivier@microsoft.com>
> wrote:
>> I agree with you that it would be useful to allow for a vendor to
>> implement an extension not intended for any kind of standards process at
>> that time as long as they properly prefix it. I believe such a mechanism
>> would be useful especially in HTML runtime environments that is *not* the
>> open web. (Silly example: A browser might expose some prefixed WebGL
>> extension (exposed to the browser add-on runtime environment only) that
>> allows the add-on developer to render 3D graphics into the browser frame.)
> In traditional GL the vendor prefix usually serves this function. However in
> WebGL we've already used the vendor prefix slightly differently (for draft
> extensions on track to be standardized).
> I'd suggest tacking on an additional prefix for extensions a vendor does not
> wish to standardize at that time, something like:
> NONSTANDARD_MS_your_extension.
> Would this be a satisfactory convention for everybody?