Re: Forms support in clients

Karl Auerbach (
Tue, 27 Sep 94 12:47:29 PDT

> > I suspect before we get into picking a language we really ought to
> > cogitate for a while and try to understant how much power we want to
> > put into smart documents.
> Yes, a very tough nut to crack. I'm glad to hear you say it, actually
> -- I spent five years of my life working on this problem, I'm glad to
> hear it isn't actually trivial!
> I suggest that you might want to read my CSCW 92 paper on the ATOMICMAIL
> language. This was a predecessor of Safe-Tcl, now defunct, but was
> based on your beloved LISP syntax. You might find some of the security
> problems in a safe LISP variant were already addressed in that work.

Is it online anywhere?

> For my part, spending several years building a safe LISP variant was one
> of the things that convinced me that Tcl was a far more appropriate
> language model for this sort of thing. -- Nathaniel

I'd be interested in hearing.

Actually I'm hardly "beloved" of lisp like languages. It took about
three years of discussion to get me out of the postscript/forth camp
:-) (And I do all of my serious coding in C++, where the rich set of
class libraries gives me a better prototying environment than I get in
most interpretive languages.)

One of reasons I do like lisp/scheme is the garbage collection -- it makes
writing long-lived scripts much easier because memory leaks become much less
of a problem.

I don't think many client/viewers are going to be amenable to having random
long-lived scripts loaded into them as a result of a URL fetch. I'm much
more concerned with what happens on servers.

I certainly would be interested if you have a short note describing
what it means to be a "safe" execution environment. I saw the note
from Osterholz (sp) from Sun about safe-TCL mentioning database
updates and I was wondering how things like that could be secured.