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

RE: [Public WebGL] RE: extension development process



Thanks Florian, Ken.

 

I agree that “fait accompli extensions” usually have counterproductive side effects; I think we all want to avoid introducing situations where the open web comes to rely on a single-vendor extension (of any sort, whether it be in HTML or CSS or network protocols, or in any other web platform feature) to function. (We’ve had to deal with some pain here: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx)

 

We like the idea of a ratified extension list; this will help ensure that vendors have a clear list of extensions to ship, and developers have a clear interoperable list of functionality to use.

 

As you said, we can't force a vendor not to implement an extension, no matter what its registry status is; no standards body has been able to reliably and adequately perform this feat.

I agree with you that it would be useful to allow for a vendor to implement an extension not intended for any kind of standards process at that time as long as they properly prefix it. I believe such a mechanism would be useful especially in HTML runtime environments that is *not* the open web. (Silly example: A browser might expose some prefixed WebGL extension (exposed to the browser add-on runtime environment only) that allows the add-on developer to render 3D graphics into the browser frame.)

 

Thanks

Frank

 

From: Florian Bösch [mailto:pyalot@gmail.com]
Sent: Tuesday, February 10, 2015 6:57 AM
To: Kenneth Russell
Cc: Frank Olivier; Dean Jackson; public webgl
Subject: Re: [Public WebGL] RE: extension development process

 

I understand the point Frank is making. After all we can't force a vendor not to implement an extension, no matter what its registry status is. A vendor might implement an extension, and then propose it, or never propose it all.

 

So here's the deal. Any vendor, at any time could start introducing extensions out of the blue, without proposing them, or taking care to get them trough the extension process. The term "fait accompli extension" would probably fit.

 

However I'd implore that such behavior is actually counter productive. If one vendor starts doing that, the other vendors will end up doing it as well. Before long, we'd end up with a multitude of slightly incompatible extensions covering the same functionality. Using the extended functionality would become very difficult for users, and other than having played another nuclear game of chicken nothing would've been accomplished.

 

So I would propose an alternative resolution to this conundrum:

  1. Khronos board members if they wish to retain their seat on the board need to adhere to the rules of the board, which includes the extension policy
  2. The extension policy for what may or may not be implemented is further tightened and clarified, not weakened.
  3. A section is added that would allow for a vendor to implement an extension not intended for any kind of standards process at that time as long as they properly prefix it

That way we can keep the standards registry useful and a green pasture for everybody to enjoy, with strong protections in place to keep it that way. But we can also have vendors implement any extension they wish, long as they are willing to abide by the rules of the prefix game for vendor only extensions.

 

 

On Tue, Feb 10, 2015 at 3:09 PM, Kenneth Russell <kbr@google.com> wrote:

Hi Frank,

On Tue, Feb 10, 2015 at 1:47 AM, Frank Olivier
<Frank.Olivier@microsoft.com> wrote:
> "Rejected extensions should never be implemented. "
>
> I would advocate for slightly different wording, with the same intent:
>
> - Vendors should avoid implementing rejected extensions.

Since the wording about "proposed" extensions is pretty strong in the
extension registry ("they should not be implemented, even under a
vendor prefix") I think the wording should be even stronger about
rejected extensions.

> - Vendors may implement experimental extensions to obtain technical feedback
> and to submit them to the ratification process.

This second one should already be covered by the existing wording in
the extension registry "Draft extensions may be implemented under a
vendor prefix for experimentation purposes". Let me know if this seems
insufficient.

-Ken



> "An extension enters rejected status because consensus on it could not be
> reached at the proposal stage or technical difficulties arise during
> implementation at the draft stage. A community approved extension can only
> be rejected in extraordinary circumstances. A Khronos ratified extension
> cannot be rejected."
>
> Agree with this wording.
>
>
>
> Thanks
>
> Frank
>
>
>
> From: Dean Jackson [mailto:dino@apple.com]
> Sent: Saturday, February 7, 2015 3:15 AM
> To: Florian Bösch
> Cc: public webgl; Frank Olivier
> Subject: Re: extension development process
>
>
>
>
>
> On 7 Feb 2015, at 5:13 pm, Florian Bösch <pyalot@gmail.com> wrote:
>
>
>
> Frank and Dean, could we get it on the record here that you're in agreement
> of this wording?
>
>
>
> Agreed.
>
>
>
> Dean
>
>
>
>
>
> On Fri, Feb 6, 2015 at 8:47 PM, Florian Bösch <pyalot@gmail.com> wrote:
>
> I have introduced the rejected status to the extension registry, added
> wording explaining when an extension can be rejected and clarified the
> process of extension advancement. Below are the added wordings:
>
> Every extension should advance to Khronos ratified. If an extension cannot
> advance through the extension process it can be rejected.
>
>
>
> Rejected extensions should never be implemented. An extension enters
> rejected status because consensus on it could not be reached at the proposal
> stage or technical difficulties arise during implementation at the draft
> stage. A community approved extension can only be rejected in extraordinary
> circumstances. A Khronos ratified extension cannot be rejected.
>
>
>
> This is of course open for debate, but I find it a good idea. Can we form a
> consensus on this?
>
>
>
>