I was actually adressing the efficiency end. I agree that a language
without syntax is pretty bad.
> Please don't take me as an anti-TCL bigot. Rather, I'm concerned that
> as we load servers with more and more interpretable blocks of code
> that what are tolerable levels of overhead will be vastly multiplied.
Well, if you're talking about uploading Tcl to the server from a client,
that's one thing. You're going to need some sort of scripting language,
and Tcl is nice because you can add new operations in assembler, C, shell
scripts, or whatever you want. Indeed it was designed for that, unlike
other languages (scheme springs to mind) wherein their environment is
closed but can be openned.
> The concern I have about "safe" environments is that they often do not
> consider the interactions which can occur between machines, i.e. as
> things travel across "safe" boundaries. We find this kind of problem
Well, you can take a SafeTcl program from anywhere and run it under your
userID without even looking at the source, and know that it's not going
to read files without you giving permission, send mail, print, lock up
your terminal, etc etc etc.
> contexts and hence cause a secrutity violation. This often happens if
> the different machines have different privileges attached to the same
> user ids or user names, for example.
Sure. But I think that's way off the topic of what we're talking about.
There, the two networks trust each other, yet the owners thereof screw
up. I am talking about when you *don't* trust the other person. That's
much easier.
> I did an interesting comparision, a TCL/TK program that did some bit
> map drawing and the ELK Scheme toolkit (that also has X operations
> built-in). The Scheme (Lisp) based approach ran circles (drew
> circles?) around the TCL/TK engine.
But the server isn't going to be running Tk stuff. The client will be
running Tk stuff.
> However, as someone else mentioned, the value of TCL is that it gives
> a means to express the sequence of execution, which just about all
> languages can do. And hence the value of TCL/TK is in TK, not TCL.
In which case the efficiency of Tk doesn't really matter, since it would
be the client running it, not the server.
> And I don't think that we are talking about documents that have
> built-in X11 display operations?
Well, X11-like operations, in the same sense that Mosaic has X11-like forms.
> But we are getting in a language war here, which is not what this list
> is all about.
No.
As I see it, there's three languages here.
1) The interface between the server and server-written code. We already
have one, called CGI.
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).
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.
> One interesting side point about languages like Scheme is that they
> are so small that it may be possible to build tools that can validate
> that the program itself is safe rather than wrapping it in run-time
> checks. But this is starting into proof-of-correctness territory, a
> black art I haven't practiced in some years.
SafeTcl's approach is to remove all elements from the language which are
unsafe, then allow the server (in our discussion) to chose to add them
back in a controlled way. No validation *or* runtime-checks.
(I can't imagine letting untrusted people run programs on my machine for
their benefit that take so long it's faster to prove they're safe than it
is to check at run-time.)
> Ah, finally what I do want to talk about. But first, I think we
> really need to understand how smart documents will interact with one
> another or spawn one another, if they do so at all, or how cgi-scripts
> interact with other cgi-scripts, if they do so at all.
Yes! Yes! With a good interface between, the language matters much less.
> The stuff I've been working on allows the creator of a
> script-in-execution to have enough control over that script to kill it
> or replace it. I don't know that this is a relevant concern to this
Well, if people here aren't interested, I'd certainly like to take it to
private email. I've been interested in safe distributed languages for a
while now. -- Darren