- From: David Sheets <kosmo.zb@gmail.com>
- Date: Sun, 18 Nov 2012 17:35:30 -0800
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
On Thu, Nov 15, 2012 at 8:51 PM, Rik Cabanier <cabanier@gmail.com> wrote: > On Thu, Nov 15, 2012 at 5:30 PM, David Sheets <kosmo.zb@gmail.com> wrote: >> On Thu, Nov 15, 2012 at 3:55 PM, Dirk Schulze <dschulze@adobe.com> wrote: >> > Just checked, animations use IDENT :P. I definitely don't want a >> > different syntax for custom() then for animation-name/@keyframes. So yes, >> > IDENT is fine for me (no quotes). >> >> What Accept header will be sent for HTTP requests of shaders with >> "format" "glsl"? > > I believe we haven't specified about that. > The shader programs are currently downloaded as text. Do you think the > programs should be requested for mime types x-shader/x-vertex or > x-shader/x-fragment? Those media types are bad for the ecosystem for a number of reasons: A. They use "x-" which has been deprecated by RFC 6648 <http://tools.ietf.org/html/rfc6648> B. They use a non-standard type (the bit before the "/") C. They use subtypes (the bit after the "/") in a media-specific way D. They fail to identify the specific media type of the content (OpenGL ES 2.0 GLSL 1.0) The Khronos Group, in their role as steward of the OpenGL ES 2.0 GLSL 1.0 language as internet standard, has been delinquent in recommending a media type for authors to use. Media type registration was brought to their attention via the public-webgl mailing list 6 months ago but was met with silence from the body <http://www.khronos.org/webgl/public-mailing-list/archives/1205/msg00160.html>. I do not believe any other entity can make a formal registration request for a media type in the standards tree; however, if I am reading RFC 6648 correctly, no formal registration is required (though one SHOULD be made). Here is my use case: I would like to host a shader resource identified by URI Q. This shader resource has several equivalent representations: OpenGL ES 2.0 GLSL 1.0 OpenGL ES 3.0 GLSL 3.0 Microsoft Secret Shading Language 1.0 A "literate program" representation in HTML A "literate program" representation in LaTeX/PDF A JSON encapsulation holding multiple representations or fallback versions Each of these representations contains links to the other representations (in the form of self-references with annotated media types or media-specific sibling URIs) as well as equivalent content in variously comments and code blocks. I would like to provide URI Q for every equivalent shader in my CSS and have the browser make a single HTTP request with appropriately ordered media types in the Accept header. A suitable shader will be returned from the server and will execute in the context of the first matching at-rule. I am interested in seeing standardization with the following properties: A. A media type in the application/* type tree (supposedly present best practice) or a new compute/* ("kernel"? "shader"? strawman...) type tree which admits only media types for numerical modules which must obviously terminate by design of each language (if you must) B. A media subtype in the type tree of (A) which unambiguously specifies the numerical language of the resource ("webglsl" or "essl" or "glsl" in this case; which pipeline stage is expected is irrelevant at the media type level as language resources may not represent an entire stage or a single resource may have multiple uses) C. A clear map between the CSS identification token string and the media type used in any network request D. An intuitive behavior for coalescing custom filter at-rules into a network request (e.g. equivalent Accept ordering) Whatever media type is selected, a version parameter should be specified. Except for this internet standards alignment, I love this proposal. This brings up some issues with related aspects: I do not understand why the programming language of a custom filter is called "format". Maybe "type"? I do not understand why the value of the format field is "glsl" which is an ambiguous name for a family of languages some of which may be used in this context in future. Perhaps "webgl" or "webglsl"? I do not understand why an IDENT should be used as the name of the language in this context when this token refers to a browser-intrinsic dictionary and should correspond directly to a media type. Additionally, if WebGLSL is recommended and default here, this field should never be necessary under normal usage. I support the use of IDENT for the identifier of the at-rule, however. I'd really appreciate your feedback on these comments. Thanks, David Sheets
Received on Monday, 19 November 2012 01:35:58 UTC