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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context

On 14/12/2010 14:08, Kenneth Russell wrote:
> It is very likely that we will wrap existing EXT_ extensions for
> WebGL. If WebGL-specific extensions used this prefix, there would be a
> namespace conflict.
> -Ken
I do not understand the above statement at all. A namespace conflict can
only arise if the rest of the extension string matches an existing EXT
extension. Since there is not a currently an EXT_lose_context extension,
there can be no conflict.

WEBGL_WEBGL should be reserved for WEBGL specific extensions that the
working group believes are significant and have been ratified by the
Khronos board of promoters. This latter step allows free use in WebGL of
any necessary member provided IP.

I see no problem with WEBGL_EXT being used for extensions that have
multiple vendor support. I do not thing we need to distinguish between
an EXT extension specifically written for WEBGL and one written for
another API that has been wrapped for WEBGL. The wrapping causes it to
become WEBGL specific.

Of course command and token names will use only the latter part of the

> On Mon, Dec 13, 2010 at 9:21 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
>> > Following the GL naming convention I'd expect them to named things like
>> > WEBGL_OES_texture_float
>> > WEBGL_EXT_texture_compression_ext1
>> > WEBGL_CHROMIUM_lose_context
> WebGL dropped the "gl" prefix from the OpenGL ES 2.0 entry points and
> the GL_ prefix from the enum values, which is why the GL_ prefix was
> dropped from the names passed to getExtension().
So would I but as far as I am concerned it does not have anything to do
with dropping of the gl prefix in the WebGL entry points. In the case of
extension names the first part is the name of the API the extension is
for, which in this case is WEBGL.

By the way, dropping the "gl" and "GL_" prefixes  is a real pain for
anyone porting existing JOGL or JSR-239 code via GWT, especially when
one wants the same code base to continue to work with its original
target API.



fn:Mark Callow
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
title:Chief Architect
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660
url:http://www.hicorp.co.jp,  http://www.mascotcapsule.com