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

Re: [Public WebGL] RE: extension development process



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.

-Ken


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?

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------