Server-side rendering engines

A recent question from Andrew Mutz prompted me to discuss a weakness
of transparent content negotiation
(http://gewis.win.tue.nl/~koen/conneg/) and a possible extension to
fix it.  As this discussion is of more general interest, I'll repost
it here.

-snip--


Transparent content negotiation is not really a mechanism to give a
server-side .gif scaler your exact screen width.  Many people find
server-side scaling evil (because of caching issues), and the draft
more or less reflects this sentiment by not trying to provide for it.

However, maybe some applications we have not yet explored
(high-quality printing?) will *require* exact dimensions to be
communicated to a server-side rendering engine, no matter what the
caching issues.  If this is the case, then transparent content
negotiation could be extended to allow this.  For example, one could
define a `send-tags' attribute which would cause the user agent to
send certain feature tag values when making a request on a
variant.

This would allow a (short) variant list like this:

 {"paper.html" 0.8 {type text/html}},
 {"paper.tex" 1.0 {type application/x-tex} 
        {features client-typeset-tex}},
 {"paper.server-typeset.ps" 1.0 {type application/postscript}
        {features !client-typeset-tex}
        {send-tags paper-size_* dpi printcolor print-gamma}}
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

in which the third variant really hides an infinite number of variants
which could be generated by the server-side typesetting engine.

When retrieving paper.server-typeset.ps, the presence of the send-tags
attribute would cause the user agent to extend the
paper.server-typeset.ps URI with the tags it supports (recognizes) and
do a get request:

 GET paper.server-typeset.ps?paper-size_a4&dpi=600 HTTP/1.1

This way, the exact tag values end up at the server side typesetting
engine.

The form submission syntax is used for downwards compatibility
reasons: this way list responses can contain a form giving access to
the server side typesetting engine.

Note that the chances for caches to optimize such requests on
typesetting engines are small.  But this may not hurt that much if, as
above, the paper.server-typeset.ps variant is only a fallback for
clients which do not have a client side typesetting engine.


Koen.

Received on Thursday, 1 August 1996 03:48:30 UTC