Re: [Public WebGL] WebGL extensions vendor prefixes again

[Florian Bösch <pyalot@gmail.com>]

I don't like the variants (1, 3 and 4) that would effectively cement one vendors prefix (whoever happens to lead the way) and we'd end up with a salad of permanent prefixes implemented by everybody. I personally like the 2 where non contentious extensions are implemented prefix less. I also like the idea of 4 where if a vendor wishes to depart from the standard draft, he would have to prefix.

However I fear a consensus on this will be unreachable, as the major point of discussion of the prefixes was to send a signal to users that these extensions they use are experimental and may disappear again, as well as prevent the proliferation of non community approved (i.e. draft) extensions into production code.

At the time this was discussed various other mechanisms (than vendor prefixes) have been discussed unsuccessfully. I personally like the rather straightforward way of the OpenGL specifications do it without conflating draft with vendor, but rather do:

- <vendor>_ = vendor only extension

- EXT_ = common extension

- ARB_ = ratified, more commonly supported and likely to appear in the next iteration of the core standard.

in a way this is what we do in WebGL but unconflating (i.e. s/<vendor>_/EXT_/g). Unfortunately we cannot reasonably follow this path or we'd end up with extension names like EXT_OES_texture_float or EXT_EXT_filter_anisotropic (as in there is a need to be able to "mirror" an extension and its prefixes for clarity yet tack on some state of our own).

I'd like to offer up my preferred solution to this conundrum again, provide an API rather than a naming convention to work on this.

gl.getExtension('extension_name') -> can get only community approved extension, but not draft

gl.getExtension('extension_name', {draft:true}) -> can get draft extensions and community approved

gl.getExtension('extension_name', {approved: false, draft:true}) -> can only get draft extensions

gl.getExtension('extensison_name', {ratified: true, draft:false, approved: false}) -> can only get khronos ratified extensions

The same extension query object would also be passable to getSupportedExtensions. No prefixes would be used to conflate extension status and application implementors could purposefully select exactly how much risk they want to run.

On Fri, Jul 20, 2012 at 9:09 PM, Benoit Jacob <bjacob@mozilla.com> wrote:

Hi,

With EXT_texture_filter_anisotropic now implementable prefix-free, this topic has come up again, but in a more concrete form than before.

Context:
 - WebGL uses "CSS-style" vendor prefixes i.e. each vendor has a monopoly on their own vendor prefix.
 - This is unlike OpenGL where vendors are allowed to implement each other's vendor-prefixed extensions.

The problem with the current WebGL situation is that we are stuck in this dilemma:

 - On the one hand we want to drop support for prefixed versions of EXT_texture_filter_anisotropic ASAP to avoid them getting too entrenched. Otherwise we may have to keep supporting the vendor-prefixed strings forever, which is bad for us already, so think about how bad it would be for a future prospective WebGL browser vendor --- they would be locked out from being able to render these Web pages.

 - On the other hand we want to avoid breaking existing Web pages which means that we're not comfortable with just dropping support for the vendor-prefixed string overnight.

The compromise we've chosen for EXT_texture_filter_anisotropic is to have Firefox 17 support both the prefixed and unprefixed versions and warn on the prefixed one, and then drop the prefixed one in Firefox 18 which will come 6 weeks later --- about 6 months from now.


The question is what can we do to avoid prefix hell next time?

Idea #1 (most conservative, incremental improvement): When an extension becomes implementable prefix-less, if all the variants of the spec (the prefix-less spec and the various prefixed specs) are identical, as is the case with EXT_texture_filter_anisotropic, then at that time it should become legal to implement each other's vendor prefix for this extension.

Idea #2: When discussing a new extension proposal, if vendors agree that it's not a contentious topic and that they will be happy with whatever other vendors come up with, then we could agree to go prefix-less right away, so the draft proposal could be implementable without a prefix. Indeed, most WebGL extensions so far have been non-contentious.

Idea #3 (variant of #2): We could instead decide to allow vendors to implement each others' vendor prefixed extensions already during draft stage. The obvious objection is that in this case, prefixes are useless and we may want to go for #2 instead, but one could argue that prefixes still serve a purpose. In particular, this would help in the case where there are two competing approaches. Vendors implementing another vendor's prefix should make every attempt to adhere to the prefixed spec; otherwise, if they want to implement a different spec, they should make their own proposal and have their own vendor prefix.

Idea #4 (the least conservative; my personal preference): just switch wholesale to the OpenGL way of vendor prefixes i.e. allow vendors to implement each other's vendor prefixed extensions. It would remain a requirement (like for OpenGL) to adhere to the spec --- vendors wanting to depart from a prefixed spec would have to use their own prefix instead. This seems to be working already quite well for OpenGL and the fact that WebGL has a tighter extension process where a proposal must have approval from this Working Group before even prefixed implementations can start to exist in the wild, suggests to me that this would work well for WebGL too.

Thoughts?

Benoit

-----------------------------------------------------------
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
-----------------------------------------------------------