Re: Semicolon's for all

Charles Henrich <henrich@crh.cl.msu.edu>
From: Charles Henrich <henrich@crh.cl.msu.edu>
Message-id: <9312312215.AA05704@crh.cl.msu.edu>
Subject: Re: Semicolon's for all
To: rst@ai.mit.edu (Robert S. Thau)
Date: Fri, 31 Dec 1993 17:15:19 -0500 (EST)
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9312311855.AA04894@volterra> from "Robert S. Thau" at Dec 31, 93 01:55:43 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2425      
> A document with server includes is not a standard text document, to my way
> of thinking --- standard text documents don't *have* programs in them.
> Rather, it's a program in a special-purpose language which is designed to
> *produce* standard text documents (as is, say, a TeX input file).  But
> that's a rather different thing.

Bullshit.  Its a text document that is parsed by a preprocessor, the
preprocessor can take arguments.  This whole argument is getting rather silly,
Im amazed at the massive pushback at adding something that wont break anything,
even when CGI is still in its infancy.  What happens in a year when folks want
to add something and CGI is well entrenched?

> It's worth noting that the use of that language has a certain cost.  The
> simplest use of server includes --- say, something like <inc srv "|date">
> --- spawns off a Bourne shell, which does at least a couple of file system
> operations before spawning off yet another process which finally prints the
> date.  A document with several includes incurs this overhead several times
> over.  And, at least for those of us who have been spared AFS, spawning a
> process costs rather more than a couple of stats.

Of course, if your running on a RS/6000 with lots of memory (as I am) spawning
and executing are virtually instantaneous as its all out of ram, and nothing
ever hits the disk or network.

> In short, I don't see that the semicolon syntax is actually necessary for
> what you want to accomplish.  Plausible alternatives are at least as
> convenient, and so far as I can tell (when the whole cost of running the
> retrieval is factored in) only marginally more expensive.

It is rediculus that to serve up documents I must spawn a huge scripting
language to emulate a server (which I already have running!).

This morning I absolutely needed the semicolon syntax to accomplish what I want
in any clean manner.  It took exactly 2 additional lines of code to the server.
Im still amazed at the inflexibilty you folks are imposing on something so new,
that hasnt even begun to be used in all possible situations it has been
designed for.  Its okay, I dont mind adding 2 lines of code to every new
release, its too bad that everyone who finds themselves in my position will
also need to do so.

-Crh

    Charles Henrich     Michigan State University     henrich@crh.cl.msu.edu

                     http://rs560.msu.edu/~henrich/