[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGLSL Media Type Proposal
On Mon, May 21, 2012 at 2:07 PM, Ben Vanik <email@example.com> wrote:
From my experience, doing 'python -m SimpleHTTPServer' to get around file:// access when experimenting is so easy that there's no excuse to not do it and put an end to worrying about file/same-origin/etc. If you're building an offline-only embedded webkit app (or something crazy like that), see the first point.
Yeah, I'm really confused by the number of people complaining about file:// access. Ben's Python server is stupidly easy to get running, so I'm not sure what good reason there is for griping about access policies. If you're more of a Node person, you can use the 5-line server that I use for all my local development:
var express = require('express');
var app = express.createServer();
Tada! No more file system restrictions.
The only case where any of the script stuff makes sense is one-off hello-world scale experiments and demos and in that case you've got a bunch of boilerplate copied in anyway - adding one line more to pull innerText out of a <script> is no biggie.
I think the Three.js examples folder has given people the wrong impression. They're not bundling everything in one file because it's a good idea, they're doing it because they want to simplify the presentation of the sample code. Standardizing something that only helps the most trivial case is at best a waste of time and at worst potentially harmful to the non-trivial cases. (I think this is more of the former category, but it's a bad idea in either case)
The only benefit I see of an IANA registration is that maybe then some syntax highlighters in IDEs (or browser inspectors) will become GLSL aware. It should *never* be used as an interchange format: GLSL is not a container format, cannot stand alone, and needs some kind of wrapper to be useful. I'd be much more interested if someone put an effort behind something similar to MSFT's FX files -- that's something that would deserve a registration and the artifacts of which could be useful across applications/providers.
+1 on needing an analog to FX files. Their usefulness diminishes in larger projects, but simply having a standardized package for a full visual effect would be valuable to anyone trying to share shaders.