On Thu, Nov 3, 2011 at 12:56 PM, Benoit Jacob <bjacob@mozilla.com
<mailto:bjacob@mozilla.com>> wrote:
I would like this to be discussed in the next conference call: are
there any objections to renaming/cloning WEBKIT_lose_context as
WEBGL_EXT_lose_context ?
It now seems that we're going to keep the WEBKIT_lose_context name
in the interim.
Mozilla should not ship anything with a WEBKIT prefix. If you want to
ship something with a vendor-specific prefix use your own vendor name,
not someone else's. That way lies utter madness.
- James
Benoit
On 01/11/11 10:18 PM, Mark Callow wrote:
For the other APIs the convention is to use EXT for
multi-vendor but not
Khronos ratified extensions. That would seem to be appropriate
here too.
It is nuts to have different names for the same extension in
different
browsers.
So the name of the extension would be EXT_lose_context. The
name string
for enabling it would be WEBGL_EXT_lose_context as extensions
always
start with the API name.
Regards
-Mark
On 02/11/2011 02:51, Benoit Jacob wrote:
On 01/11/11 01:41 PM, Adrienne Walker wrote:
El día 31 de octubre de 2011 14:53, Benoit
Jacob<bjacob@mozilla.com <mailto:bjacob@mozilla.com>>
escribió:
In the case of WEBKIT_lose_context, since it is so
simple and useful
for all
browsers, I would really like it to become
WEBGL_lose_context. Does
anybody
object to that and what steps need to be taken to
make that happen?
There was some previous discussion about this here:
http://www.khronos.org/webgl/__public-mailing-list/archives/__1012/threads.html#00092
<http://www.khronos.org/webgl/public-mailing-list/archives/1012/threads.html#00092>
At the time, there were reservations about adding the
WEBGL tag
without more general approval or ratification from
Khronos.
Thanks, I didn't remember this conversation. Since it
seems to have
been such a large debate, for now we will just rename it to
MOZ_lose_context on our side until consensus for
WEBGL_lose_context
happens.
Can I go ahead and add MOZ_lose_context to the registry?
I disagree with the arguments that WEBGL_lose_context is
not needed as
it could be implemented in pure JavaScript. A big focus at
the moment
is to get Web developers to care about
contextlost/contextrestored
events. It would help if we could just point them to a
WEBGL_lose_context extension to test their app's behavior
in all
supporting browsers, rather than having to use a shim for
all WebGL
entry points.
Cheers,
Benoit
-enne
------------------------------__-----------------------------
You are currently subscribed to public_webgl@khronos.org
<mailto:public_webgl@khronos.org>.
To unsubscribe, send an email to majordomo@khronos.org
<mailto:majordomo@khronos.org> with
the following command in the body of your email:
unsubscribe public_webgl
------------------------------__-----------------------------
------------------------------__-----------------------------
You are currently subscribed to public_webgl@khronos.org
<mailto:public_webgl@khronos.org>.
To unsubscribe, send an email to majordomo@khronos.org
<mailto:majordomo@khronos.org> with
the following command in the body of your email:
unsubscribe public_webgl
------------------------------__-----------------------------