[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
- 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
- The extension policy for what may or may not be implemented is further tightened and clarified, not weakened.
- 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.