[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL URI Extension Proposal
On Thu, May 17, 2012 at 6:27 AM, David Sheets <firstname.lastname@example.org> wrote:
As tool developers without a blessed way to declare our language
extensions, we are harming ecosystem interoperability. Our tools can
work together and make our lives easier by cooperating if we have a
standard way to declare our non-standard extension use.
My explanations may be confusing or unclear and if you don't
understand my reasoning, please don't hesitate to ask. :-) Most likely
I have simply not explained my proposal well enough.
You're gonna accuse me of setting up a strawman again, but what you say amounts essentially to: "All JS preprocessors and template frameworks should declare an URI serving as a canonical identifier for their syntax, only thus will the various libraries and tools be able to interact."
I think this is a flawed assumption on many levels, and I'm not arguing against URIs.
- Just having URIs doesn't solve anything by itself, it requires that users strew around the URI white-noise around their code and that the various tool implementors are aware of and go trough the specification of each other toolset and see how they can interoperate with it.
- Making various components of their apps interoperate is usually the job of the developer using them, adding glue/facades/wrappers etc. as needed if these toolkits are not prepared to work together, and if they can't work together in a transparent fashion.
- Many tools can work together entirely without knowledge about other tools, because they can work transparently and don't have to know how.
- Even if you can make everyone who writes tools agree, and even if you can convince all users to strew around URI whitenoise, and even if you can convince every toolkit writer to venture on a lifelong search for URIs he can find to interoperate with, that still doesn't "solve" interoperability problem. Not all extensions are straightforward syntactic suggar and transmoglification of one flavor of turing tape to another. Often what toolkits do is transparent or entirely semantic, not syntactic suggar. Often what a toolkit does can't even be described in some kind of transmoglification scheme.
Regardless of that, it's the WSGI debate all over again. At some point in the WSGI community there was "the great interoperability debate", where people argued that a flat dictionary and simple return type was a bad way for stacks of WSGI tools to interoperate. People where arguing passionately that this would hinder future growth and be a great pain for users etc. Somebody went out and wrote a toolkit for stratified WSGI layer management and deployment. Fast forward, nobody uses that framework, WSGI2 never happened, people happily chug their apps along with little or minor irritation at the occasional snippet of glue to write.
Grand interoperability debates never go anywhere, because they try to solve an insanely hard problem using sweeping future prophecies as arguments and propose solutions that require everybody to agree.