First and foremost, I applaud your interest in getting remotely executable
data objects into the Web. Since Tim Standish made the original suggestion
for "active messaging" in 1970, the idea of sending off useful snippets of
code has been tantalizing, but reserved for the research world. We are
finally starting to see it show up in real-world scenarios.
Having said that, I'd like to encourage folks to think carefully about the
real requirements and especially hard about the hard parts. My own belief
is that universality and safety are the to major requirements. The latter
is particularly difficult.
"Efficiency" of execution is not irrelevant, but likely to be far less
critical for most applications than most of us tend to think. Why is that?
Well, most of what is likely to be done is not intensive distributed
system computation. It is likely to be simple transactions. The mobile
code acts as an agent for the originator and it interacts with the remote
system to get and give some data.
The lesson on the Internet is that the best way to achieve universality
(i.e., an infrastructure with large-scale interoperability) is by keeping
things simple and uniform, particularly seeking to make the incremental
function known only to the end-points that are participating and not
require any changes to the connectivity infrastructure.
The best way to achieve safety is to have a limited core set of
capabilities and then provide very careful interfaces to required services.
(The user interface concern that Nathaniel expressed clearly is important,
but I believe that it frankly is secondary to the technical constraints on
resource access. But then, I don't trust users to pay close attention even
to well-done queries from their software...)
Safe-TCL was designed to satisfy these requirements. Peculiarities of
programming in TCL notwithstanding, it is a simple language and the
interpreter can run on any platform easily. (TK is less trivial, but is
proving also to be portable.) Safe-TCL carefully crippled TCL, to make it
safe, and then provides access to interfaces for "modules" of specialized
service. I believe that the details of the chosen language are not all
that critical, since it only needs to be reasonable, not "intuitive" or
otherwise perfect. End-users are not going to be the typical programmers
for these agents.
Few such modules have been developed, yet, so that the real work is to
start exploring extension to Safe-TCL, defining generic modules (e.g.,
calendar schedule is a personal favorite; workflow management might be
another; how about simple product purchasing?...) This leaves a repertoire
of "virtual services" at each participant's site. Then we can develop
different kinds of mobile agents to interact. My distributed meeting
scheduler might move around and conduct scheduling in one way; yours might
do it differently. Both would interact with the remote sites through the
same 'calendar' interface. (The concern for 'efficiency' gets addressed by
the implementation of the interface primitives on the remote site. They
are, in effect, the instructions to the virtual machine for the specialzed
service.)
In other words, let's try not to make the major part of the effort be
definition and implementation of the platform. I fear that work on a
highly general, virtual 'machine' environment would result in such a
distraction. Instead, let's use the considerable effort that has been put
into Safe-TCL and build on it, creating some useful Internet services.
d/
p.s. this should not be restricted to the Web. The same sorts of things
should be available through email. Most of the world doesn't have high
speed web access, remember.
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu