>The language issues are being "discussed" on other lists. And the
>issue that I'd rather keep dealing with is whether it might be
>a worthwhile extension to the current architecture to allow
>users to run scripts in the servers.
And I think [the light goes on slowly for me] that you're
advocating a generic extension. Right? Not bound to a particular
language?
>A lot of people are saying "what's the value" or "it wouldn't be
>secure" or "it would be a burden on the server". All good questions.
>
>And some people have shown that cgi scripts in conjunction with other
>background programs can do some of this kind of work, and can make use
>of e-mail as an ad-hoc back channel.
The thing about CGI scripts is that they're under control of
the server's sysadmin or (better sometimes) the data maintainer(s).
In either case, the language(s) locally available are known and/or
can be acquired and installed. CGI isn't Perl (thankfully).
What worries me, if we are in fact talking about the
general case, is that a client might try to get a server on, say,
a VAX to run a script written in, say, REXX. It ain't gonna fly.
Gary Adams quotes Lilia Carol Scott:
<blockquote>
... In recent years many UNIX programmers have turned
to VHLLs for rapid prototypes and complete applications.
They take advantage of these languages' higher level of abstraction
to complete projects more rapidly and easily than they could
with lower level languages.
</blockquote>
Indeed! Hear here: "rapid prototyping". Bravo!
Actually, VHLLs are applicable to full-blown applications as well.
For example: Richard Schafer's MAILBOOK, which is entirely written
in REXX with perhaps one or two lower-level shims.
<blockquote>
While VHLLs such as TCL, Perl, Icon, and REXX have gained
widespread use and popularity, ...
</blockquote>
All four of which qualify as "CGI scripting languages".
(I'm winging it with Icon; can it in fact access environment vars?
seems like a safe bet)
> --karl--
-- Rick Troth, <rmtroth@aol.com>, <troth@ua1vm.ua.edu>, Houston, Texas, USA