Re: <inc> in ncsa server (Rob McCool)
X-Delivered: at request of secret on
Message-id: <>
From: (Rob McCool)
Date: Thu, 7 Oct 1993 17:49:41 -0500
In-Reply-To: (Charles Henrich)
       "Re: <inc> in ncsa server" (Oct  7, 11:27am)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: (Charles Henrich),
Subject: Re: <inc> in ncsa server
 * Re: <inc> in ncsa server  by Charles Henrich (
 *    written on Oct  7, 11:27am.
 * Well I can see one problem with it, and thats that it will take alot 
 * more work to produce the document on the fly.  The server has to ingest 
 * it, pass it off to the preprocessor, which then hands it back.  Also how 
 * would you include the output of programs in such a method?  Just seems like
 * its a lot more work for what essentially would accomplish the same thing.
 * A lot more work for the people who have to code it to.

What I see is a pipeline approach, like the shell uses (which is also what
Tony has in Plexus) allowing you to apply more than one filter to a document
to get your final document. I see no reason why you would not be able to
include the output of a program in this approach, since the filter can
return whatever it wants to the server. In addition, the filter does not
necessarily have to be a separate program, it can be within the server.

My main problems with the current setup are that people are creating HTML
documents with the INC tag, then running both NCSA httpd and anoter server
(or switching to another server altogether) and having the new server not
support the INC tag. This is why I think that documents that use the INC tag
should NOT be considered HTML documents. This also alleviates the fact that
the server is currently applying the INC filter to every HTML document when
it does not have to.

I also think that a document-type to document-type filter/conversion system
is something we will eventually have to address in the protocol, and that
this sort of thing belongs more as a filter than an HTML feature.