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

Re: [Public WebGL] WEBKIT_ extensions



No objection on my part to renaming the extension.

-Ken

On Thu, Nov 3, 2011 at 12:56 PM, Benoit Jacob <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.
>
> 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>
>>>> 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
>>>>
>>>>
>>>> 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.
>>> To unsubscribe, send an email to 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.
> To unsubscribe, send an email to 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.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------