[6004] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: How about a Safe Virtual Machine?

daemon@ATHENA.MIT.EDU (Dave Crocker)
Mon Oct 3 18:07:26 1994

Date: Mon, 3 Oct 1994 22:58:57 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: dcrocker@mordor.stanford.edu
From: dcrocker@mordor.stanford.edu (Dave Crocker)
To: Multiple recipients of list <www-talk@www0.cern.ch>

Daniel, et al,

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



home help back first fref pref prev next nref lref last post