[Still catching up after our weekend power outage at Bellcore]
While I concur wholeheartedly with what Ned said, and while I agree with
what Tim said as well about the suitability of HTML for many of the
things you're interested in, I think I can contribute two more things to
this discussion -- some philosophical thoughts about the nature of
enabled mail, and some practical information about getting safe-tcl.
PHILOSOPHY
First, some background: I've been working on "enabled mail" systems for
years now. In fact, a little known bit of history is that my previous
"active mail" system, called ATOMICMAIL, was in some small measure
responsible for getting the MIME effort started. I wanted to give
ATOMICMAIL capability to everyone in my lab at Bellcore without making
them all change mail readers, and this led me to patch all the mail
readers in the lab. Soon I generalized this patch, creating the
metamail program for a second level of indirection and configurability,
calling different programs based on the content-type field value.
Shortly after I had this up & running, the IETF-822 list was formed, and
I used my experience with metamail to inform the process of defining
MIME. All this is by way of explaining that I've been working on &
thinking about this problem for a LONG time. ATOMICMAIL was actually my
third effort in the active mail area. Safe-Tcl, the fourth such effort
with which I've been involved, is by far the most powerful, complete,
and exciting. Among other things, it has language-level support for the
notion of multiple user interface styles, it has a level of
extensibility I had previously been unable even to imagine making
compatible with mail-appropriate security, and it has MIME-smarts that
allow it to display arbitrary MIME entities (video, audio, images, etc)
under program control. It's cool beyond belief, by far the most
exciting technology I've ever been associated with, cooler than Andrew,
MIME, and metamail put together. Wait till you see the demos....
Anyway, as I see it, the real long-term problem is one of creating
infrastructure. As anyone on this mailing list surely knows, it is HARD
to upgrade the global mail infrastructure. Getting to the point where
everyone in the email world has MIME capability is an incredibly hard
goal. The situation is even harder, I believe for interactive mail,
because it is trickier. You have to worry not only about the kind of
deployment issues involved in other MIME types, but also some VERY
serious issues of security, user interface portability, and compatible
multiplatform implementations of a real programming language. This is a
HARD thing to make universal. It's very important that we do it right.
Now, doing it right will, I believe, create a fantastic and
unprecedented new global networking infrastructure. Basically, it gives
you the ability to do RPC to human beings, that is, to create complex
applications that can reach out (asynchronously) to anyone on the net,
ask them a question, get the answer in a structured form, and continue
with a computation. This is unprecedented. I've had a few really wild
ideas for entirely new types of applications you can build this way, but
I'm sure I've only scratched the surface. The technology has truly
revolutionary potential, but that potential can only be realized if it
is widely deployed, which I believe means it must be an open standard
with all the technical qualities I alluded to above. (A product like
Lotus Notes gives you a BIT of the flavor of what is possible, but for
the vision to work with Notes, everyone in the world would have to use
Notes. The real goal is an interoperable format for active messaging
that can be used by all vendors, all software, all platforms.)
Anyway, as I said, getting any such language widely deployed is going to
be a long, hard process. Once it is done, it will be a long time before
a second such language comes along to replace it. To me, this is a
strong implication that the language needs to be pretty darned powerful.
Rhys' point about the relative complexity of Safe-Tcl and a
hypothetical forms language has some merit -- though Ned is right about
the quality and portability of John Ousterhout's freely reusable
implementation -- but I would contend that the technical effort involved
in implementing almost any language -- even "Safe-Ada" -- pales into
insignificance next to the political, social, and standardization issues
involved in carrying such a language through to widespread deployment.
Even if (and I don't believe this for a minute) Safe-Tcl is 100 times
harder to implement than <your-favorite-simple-forms-language>, this
probably only makes the overall effort involved in managing the global
deployment of such a language 1% harder at most, because implementing
the language interpreter is NOT the hard part, really. Thus we don't
gain much from skimping on the language. Since the hard part is
building consensus, standarizing the language, and getting it widely
deployed, I'd hate to get through all that only to find that we need to
start over because the language isn't really powerful enough! (On the
other hand, I do think that this process will be helped greatly by
eschewing needless complexity. In fact, I think Tcl gives you an
incredible ratio of power to simplicity, which is why I'm pushing it as
the right language model these days. Turns out Tcl syntax is almost
trivial, and much of what you think of as syntax is actually just
command language, or command-specific syntax.)
Now Rhys correctly pointed out that for a large class of applications --
form processing -- a much simpler language would do. This is true. But
there are other applications where that language won't suffice. Does
this mean we need two languages? Three? Ten? The truth is, I'm not
sure. But I'm inclined to push on a really good general-purpose
language that will subsume nearly all of the enabled mail applications
I've heard proposed. If a parallel effort standardizes a smaller
language for a specific purpose, such as HTML, I have no problem with
that at all, and in fact can see a lot of utility in it, but it's not
where I'm inclined to focus my efforts because I'm almost obsessed with
the larger vision of general purpose mail-enabled applications. (You
should see some of the Safe-Tcl demos we've got already!)
One could make a similar argument that PostScript is far more powerful
than most document production systems really need. It's true. But by
having such a powerful programming language as the de facto standard
printer interface, we make it possible for simple word processors and
incredibly complex visualization software to share printing
infrastructure. Think of Safe-Tcl -- or it successors -- as the
PostScript of the email world. That's the right model. Building a
PostScript printer is a bit harder than building a simpler printer, but
it buys you an incredible amount of compatibility and extensibility.
And just as people don't really write postscript programs, but instead
interact with programs like word processors that spit out postscript on
the back end, so too I expect people will interact with programs (forms
generators, survey generators, event schedulers, etc., etc.) that give
them a nice task-oriented graphical interface and spit out Safe-Tcl on
the back end.
Anyway, that's my vision for all this. I hope this message made it
clearer rather than muddier. Now for some more practical information.
SAFE-TCL AVAILABILITY
The Safe-Tcl project has been in fairly high gear since June, roughly,
is coming along nicely, and though it is not yet publicly available it
will be soon. Some details:
1. There are publicly available documents in pub/nsb/st/* on
thumper.bellcore.com, but they're out of date. The mailing list got so
big that Marshall & I went underground for a while to try to converge on
a complete system that we were both happy with. So those documents
are an informative starting place, but not a good place from which to
start programming or implementing.
2. Marshall & I have had a complete safe-tcl implementation for about
10 weeks now, and it has been in limited alpha-test for a while. Right
now we're putting the finishing touches on upgrading it to the latest
Tcl/Tk (7.2/3.5), after which we will go to a much more open beta
testing period. If you subscribe to the mailing list (by sending mail to
safe-tcl-request(_at_)uunet(_dot_)uu(_dot_)net) you'll hear about the beta
availability,
which I hope will be in the next couple of weeks. At that time, we'll
also make available the updated versions of the specification documents,
so that the spec & code will actually match. (Novel idea, eh?)
If there's enough interest, I can cross-post the announcement about beta
availability to ietf-822. But frankly, if you're really interested, you
should join the safe-tcl list, as I'm sure there are people on ietf-822
who would just as soon skip the safe-tcl-related discussions.
As usual, I apologize for the length of this post. Some day maybe I'll
learn to be more terse.... -- Nathaniel