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

Re: [Public WebGL] WEBKIT_ extensions

On 18/11/2011 11:18, Glenn Maynard wrote:
Of course there's a risk of divergent implementations, because once they write their initial implementation, people get to use it in practice and figure out what's wrong with it.  There's always a "risk of divergent implementations" if there's any chance that your first try at designing an API isn't the one you finish with.  With nontrivial APIs, that's more of a guarantee than a chance.
That is why in the OpenGL scheme of things there is a progression from vendor prefixes to EXT to ARB|OES to core specification. Initially vendors do their own thing. When multiple vendors find common ground they merge features and come up with a common EXT specification whose further development is enhanced by the efforts of all the vendors involved. After that it may be adopted as ARB|OES.

The lose_context extension has unquestionably reached the point where multiple vendors agree on its utility and are willing to cooperate on and share any future improvements to it. So it fits EXT.

Everyone's implementing the same extension.  The only difference is that it's temporarily exposed under a different name.
And then everyone who is using it (a far larger number than the number of implementers) needs to write a wrapper so their application can call the function under a single name regardless of browser. That is why I hate vendor prefixes unless the thing truly is single vendor. (Yes, I realize this a weaker argument for WebGL as only the single call to enable the extension is affected.)

The other issue I have with the way extensions are handled in web APIs is that I can't tell the level of support for an extension. If only a single browser vendor is supporting something, I almost certainly don't want to use it. It multiple vendors support it then it becomes more interesting. Other than by drowning in whatwg e-mails how can I tell if some feature is going to be widely supported and therefore worth my interest? "EXT" serves a useful purpose for this too.

So I would urge the web API community to consider adopting OpenGL-like extension naming rather than beating on WebGL to adopt theirs.