[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] RE: extension development process
I agree with not complicating the extension registry further until
there is a specific need for it.
In my opinion, adding an extension proposal for a vendor's particular
extension idea is a viable option.
On Wed, Feb 11, 2015 at 11:48 AM, Olli Etuaho <firstname.lastname@example.org> 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: email@example.com <firstname.lastname@example.org> on
> behalf of Florian Bösch <email@example.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 <firstname.lastname@example.org> 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 <email@example.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 <firstname.lastname@example.org> 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 email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: