Re: Languages (was Re: Forms support in clients)

Darren New (dnew@sgf.fv.com)
Wed, 28 Sep 1994 15:16:49 +0100

> Ack! Maybe I just don't have my thinking cap set on correctly, but what
> application would involve public, anonymous users sending code to the
server
> to run, who wouldn't otherwise have a login account on that system or are
> "trusted" anyways?

How about I want to query the New York Times database and get back a list of
all their URLs that have the mention of a guitar in them?

What if I want to search the picture database as well? *I* know how to find
guitars in pictures, but it's not the sort of thing you build into a search
engine.

> Wait - here's a new tack on the client-side safe scripting languages
problem.
> There is a certain set of actions that are "unsafe", and so far the debate
> has been over what can be done to get a safe language for the WWW.
Instead,
> why not create a safe-environment-shell, in which a script in *any*
language
> that the client can understand can run, and when it attempts to do
something
> labeled as unsafe, the user is prompted for validation (or gives his
consent

And hey, why not call that shell "Safe Tcl"? ;-)

Seriously, if I'm running under ms-dos and you send me a C program, how do I
keep it from messing things up? I mean, I would have thought the finger
protocol was pretty easy to get right, you know? The morris worm I think
pretty plainly shows that you can introduce loopholes in even the simplest
things if you're sloppy. It's clear to me that what you want is a specific
list of things allowed rather than a list of things disallowed.

And even if awk, perl, tcl, glump, floop and splurg have all been ported to
DOS, I might not want them all installed on the off chance that someone out
there might want to use one for something. That's half the impetus that
keeps C alive (flames to email, please).

-- Darren