Needs to be extended, but yeah, it's pretty good for what it does.
> 2) Programs that people send to a server from untrusted clients to be
> executed on the server's hardware. This I would think should be an
> easily-extendible language. This seems like the kind of thing where
> either an operation doesn't get executed very often (in which case it's
> better to interpret it) or it's something that should be compiled in (in
> which case you want to extend the language, or use 1 above).
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?
> 3) Programs imbedded in documents to be sent back to clients, like
> sophisticated forms. In this case, efficiency isn't much of a concern,
> since you're already running X and stuff, and there's only so many
> programs whose output you can watch at once.
> Since #2 is the real efficiency-problem, it's clear that Tk isn't the
> problem, at least to me. The problem is the efficiency of the code
> runing on the server on behalf of the clients. Since the kinds of stuff
> I'd let people run on my server without checking it fall into a few
> categories, I would think I could extend my language to cover them
> efficiently, just imagining for 5 minutes off the top of my head.
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
on certain actions by default). I doesn't seem like it would be too
difficult to create this shell, though I don't know what the performance
hit would be like. For example, I could put up a Perl script to do the
Xerox map generator, the mime type of which would be
application/perl
and that type is mapped to
application/perl; safecsh perl
I guess this is similar in a way to Vinay's vsafecsh, at
http://www.eit.com/software/vsafecsh/vsafecsh.html
though a bit more extensive in that you don't declare the safe programs,
you declare the safe system operations. Also nice would be added
security like zero-ing out any memory the application might want to
allocate. This solution is indeed platform-specific, but it's only
platform-specific at the client level - many scripting languages have
been ported to every major platform. And for the non-faint-of-heart,
compiled languages could work similarly - downloading a C program, having
it compiled, and starting it all with one click of a button would be just
too cool.
Now, this *still* doesn't solve the question of creating dynamic user
graphical interfaces, I admit - but that's a whole different can of worms.
What I'd like to see is a list of applications that require their own user
interface that *can't* be done using either client-side plug-ins or giving
more oomph to HTML (there's lots that can be done with the LINK element, hint
hint). My guess is that the list is small, and the applications so intensive
- 3-d object viewer comes to mind - that expecting a scripting gui
language to do that would be asking... a lot.
Brian