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

Re: [Public WebGL] Re: WebGLSL Media Type Proposal



On Mon, May 21, 2012 at 7:06 PM, James Robinson <jamesr@google.com> wrote:
>
>
> On Mon, May 21, 2012 at 7:00 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>
>>
>> On Mon, May 21, 2012 at 5:54 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> > On Mon, May 21, 2012 at 6:26 PM, David Sheets <kosmo.zb@gmail.com>
>> > wrote:
>> >>
>> >> We must first have a type declaration before we can discuss what
>> >> standard mechanical specialization should be keyed off that type.
>> >>
>> >> The sooner we can achieve media type registration, the sooner
>> >> interoperable Web-harmonious WebGLSL web services and serialization
>> >> formats can be deployed and independent developers can build on the
>> >> common type name.
>> >
>> >
>> > This is a lot of furious yet vague handwaving; I haven't a clue what
>> > you're
>> > trying to say.  ("Standard mechanical specialization"?  What?  According
>> > to
>> > Google, nobody on the internet has even used that series of words
>> > before.)
>>
>> Discussions of <script> @type and HTTP Content-type behavior are
>> discussions of special automatic (mechanical) software behaviors based
>> on a standard name.
>>
>> > If there's a real problem you're trying to solve, then please explain it
>> > clearly and concisely, so we can figure out why anybody should spend the
>> > time figuring this out.  Until then, we're all writing GLSL scripts just
>> > fine.
>>
>> In general, the problems I am trying to solve are of two varieties:
>>
>> 1. Payload declaration for content-agnostic transport protocols
>> 2. Payload declaration for content-agnostic transport formats
>>
>> Here are a couple problems that demonstrate these issues:
>>
>> 1. What is the HTTP Content-type header value for WebGLSL source
>> resources?
>
>
> When does it matter?

When using HTTP content negotiation to serve different aspects of the
same resource. For instance, a WebGLSL resource could be either an
HTML page describing the shader, an FX file containing the shader, the
raw shader source text, a JSON encapsulation of the shader, or a LaTeX
document typesetting the mathematics embodied in the shader.

>>
>> 2. What is the script/@type value for WebGLSL source embeddings?
>
>
> When does it matter?

When writing a program to extract WebGLSL shaders from pages that
embed them in semantic <script> tags, the type of the enclosed source
is a key piece of metadata.

More generally, when transporting or serializing different
representations of same mathematics embodied in a shader, the media
type is an extremely helpful field to distinguish different
representations.

David

> - James
>
>>
>>
>> My media type proposal has nothing to do with *writing* WebGLSL
>> programs and everything to do with *handling* WebGLSL programs.
>>
>> Please let me know if you have other questions or concerns.
>>
>> David
>>
>> > --
>> > Glenn Maynard
>> >
>>
>> -----------------------------------------------------------
>> 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
>> -----------------------------------------------------------
>>
>

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