Re: <inc> in ncsa server
robm@ncsa.uiuc.edu (Rob McCool)
X-Delivered: at request of secret on dxcern.cern.ch
Message-id: <9310080616.AA23943@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Fri, 8 Oct 1993 01:16:04 -0500
In-Reply-To: Charles Henrich <henrich@crh.cl.msu.edu>
"Re: <inc> in ncsa server" (Oct 7, 8:07pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Charles Henrich <henrich@crh.cl.msu.edu>, www-talk@nxoc01.cern.ch
Subject: Re: <inc> in ncsa server
/*
* Re: <inc> in ncsa server by Charles Henrich (henrich@crh.cl.msu.edu)
* written on Oct 7, 8:07pm.
*
* >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.
I don't see how. As I said, the filter does not have to be a separate
program to the server.
Consider this. Currently, the function send_fd is split into two versions:
the html version which does INC parsing if the option is turned on, and the
non-html version which just spits a file out. Assume we make send_fd into
separate functions. So, we have a dumb send_fd, a send_fd for the macroized
HTML (which would probably be EXACTLY like the current one, unless we change
the <inc> syntax). We would then have other send_fd's which would work on
future type conversions, which could either rely on external programs or
internal functions.
Does this seem clearer? Is there something I'm missing which would make this
approach slower?
* >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.
Exactly. While it doesn't really matter if it's #inc or <inc>, the point is
that it is not HTML anymore and documents which are plain HTML should not
have the processing done on them. Also, people should not be encouraged to
think that <inc> is part of HTML (at least, not the way it is right now,
since I don't believe there are any <inc> directives for clients).
* (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.
*/
--Rob