Re: <inc> in ncsa server

Charles Henrich <>
X-Delivered: at request of secret on
From: Charles Henrich <>
Message-id: <>
Subject: Re: <inc> in ncsa server
Date: Thu, 7 Oct 1993 20:07:32 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1708      
>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.

The problem with this approach, is that is will probably end up being
considerably slower than the current case.

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

Perhaps I shouldnt have chosen to patter the include directive after HTML, for
all it matters it could be #include.  Its not meant to be HTML, for example,
the C compilers do not understand '#' directives, only the preprocessor does.
In our case the NCSA server is the preprocessor, and the Web Client is the
compiler.  If it will alliviate the problem, lets just rename it to
#inc "item".  As people *shouldnt* be thinking of this as an HTML addition.

(Although now that I think about it, I had patterned it after HTML because I
was hoping at some point people would allow <inc clnt "URL"> as well.  Where
the client would then go and include the document.