I think trying to choose and anoint "THE" language for the
Web would be divisive and split the Web community into non
communicating camps. After all - one of the great features
of CGI is that it is language independent - it hasn't excluded
anyone.
I think that some of the focus on sending procedures, safe or
otherwise, is due to an unclearly defined problem. No flame
intended on Nat Borenstein and others - *I'm* one of the ones
experimenting with the idea too, but I think _experimenting_ IS
the operative word here. If we knew more exactly about what we
wanted to do, we could come up with a non-procedural description.
( Which is clearly the safe-est representation of all! )
Particularly on the client side, a non-procedural description would
be (IMHO) more in the spirit of the Web/HTML/etc. ( Server "agents"
may be another matter entirely ) Even with a safe system, I don't
know if I want to give that much control over presentation, popping
up windows and asking me questions, etc. to an outside entity.
These is a domain for this: I'm using Mosaic as a poor man's GUI
for some internal projects, but I'm not sure if that makes sense
in the wider world of the Web. I've read the safe-tcl papers and
I've said before that I'm not convinced that (please read all the
qualifiers here) the fine grain of control that I would like is
easily specifiable. ( I don't mean that as much in the realm of
enabled-mail as in trying to extend it into other areas.) With
a non procedural description, you can look at it and decide that
you want to display or react to it differently. I think Dan Connolly
pointed out the problems of PostScript and Tex representations -
you don't know WHAT the heck it represents *until* you have executed
it. A higher-level, non-procedural description doesn't have that
problem, it specifies WHAT should be done, and not HOW.
A client-side equivalent of CGI would definitely be nice, but
considering the greater variation on what can be relied upon on
the client side to implement things, I'm not sure how much can
be done. On the client-side, we have to deal with a lot more
proprietary stuff: DDLs and OLE, AppleEvents, etc. The only thing
there that looks like it will be portable enough NOT to make our
life MORE difficult is OpenDoc. ( Exactly how *Open* is OpenDoc ?
Can we get the full specs without paying money to join the CIL
consortium ? )
[ The ILU stuff from Xerox looks promising, but I haven't yet
digested the documentation. ]
Again: no slam on safe-tcl or Nathaniel's work intended. I encourage
he and others to pursue this project. I intend to. ( My interest
in doing it IN Python, rather than just adopting safe-tcl, is due
to the fact that my interest didn't start with enabled-mail, but
with trying to support collaborative and distributed programming
IN Python. I came across his papers on safe-tcl as one of the
best thought out works on the subject. I understand his desire
that for it to be an effective standard, defacto or otherwise,
he would rather see people adopt his scheme that putting energy
into a "competing" product. But adopting safe-tcl won't get me to
where I'm going. ( But I'm certainly going to install it and try
it, and give it a chance to dispel some of my concerns - but if
I adopt it for enabled-mail, it still won't stop me from trying
to get a safe-Python for other purposes. But thanks for the
path-breaking work on this! )
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]