[6000] in www-talk@info.cern.ch
Re: Forms support in clients
daemon@ATHENA.MIT.EDU (Karl Auerbach)
Mon Oct 3 15:15:09 1994
Date: Mon, 3 Oct 1994 20:11:34 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: karl@cavebear.com
From: Karl Auerbach <karl@cavebear.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
> >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?
Right. I can't even remember scheme/lisp long enough to read a
program, much less write one. :-) The only reason I even brought up
scheme was to illustrate that there are alternatives to TCL. (I *am*
using scheme in other contexts, but not for code I expect humans to
write.)
I really like the saying "everything in computer science can be fixed
by adding another level of indirection." Of which I find "late
binding" to be a corrolary.
Having hooks where one can hang a complete program language seems to
me to be a way of adding indirection and late binding.
We see this in CGI scripts, where the script itself performs the binding
between the URL and the content that is delivered over http to the client.
I'd like to see a generalized execution environment for me, as a
client, to run sophisticated, perhaps long lived, queries. I can do
it as a client, but it involves polling using http. I'd rather make
it more efficient.
> >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).
The trouble with CGI, however, is that it tends to require the
sysadmin to anticipate all ways that I, as a client, might want to
search or aggregate or summarize the document space offered by the
server (or the other servers I can reach.)
> 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.
Nah. I've been thinking of IBM MVS JCL as the script language, perhaps
with RPG or APL extensions. ;-)
(Well, what did you expect from someone who helped build the first
Internet toasters?)
--karl--
