[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 1:26 AM, Florian Bösch <pyalot@gmail.com> wrote:
> On Thu, May 17, 2012 at 6:27 AM, David Sheets <kosmo.zb@gmail.com> 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."

You are correct that this is a misrepresentation of my position. My
position is actually:
"When tools processing formal languages wish to describe and consume
source using language extensions, a standard method should be used."

The OpenGL ES WG clearly agrees with this statement by inclusion of
the #extension preprocessor directive.

I am simply advocating the expansion of #extension's namespace to the
namespace of the Web, URI.

> 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.

It requires nothing from users unless they wish to use extensions
named by URI. Tool developers will always have to analyze their source
and target languages. My proposal is for a common *standard* way to
express extension names in the Web namespace for those who wish to use
it. A mechanism of this sort belongs in the *Web*GL extension
registry/standard because it defines the relation between RFC 3986,
the Web's namespace, and WebGL, a new Web browser API.

> - 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.

It is the job of the tool developer to lessen this hackery. Quite soon
CSS3 will accept custom() shaders for DOM elements and those authors
will not care *at all* about glue/facades/wrappers. Using a standard
syntax for URIs as extension names greatly improves the ability for
tool developers to build interoperable tools.

> - 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.

Using URIs does not solve every problem tool developers face but is a
necessary precondition for web-scale tools.

> 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.

That is a different debate with different circumstances. My draft is
proposing a simple combination of RFC3986 URIs (a ubiquitously
deployed and massive successful naming system) and *Web*GL.

> 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.

This proposal only requires agreement from those who wish to use URI
as an identifier type for extensions. RFC3986 (STD 66) is well-known
and well-understood. The combination of RFC3986 and WebGL is quite
simple. How is this problem insanely hard? I am only seeking agreement
regarding the interaction of these two Open Web Standards.


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