Loading ...
Sorry, an error occurred while loading the content.

Server-side rendering engines

Expand Messages
  • Koen Holtman
    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
    Message 1 of 1 , Aug 1, 1996
    • 0 Attachment
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.