> The WhitePaper that I mentioned the other day about reasons> for and against mobile (itinerant) agents can now be found in> "http://www.research.ibm.com/xw-d953-mobag-ps" (yes, those are> all hyphens). The URL may change in the next few weeks, as our> external-web stuff is still very new. (If anyone has any> trouble getting to that URL, let me know!)

Thanks for the paper - I think you covered a lot of the pros and
cons. However, I'ld like to offer a different perspective on the
"Why mobile agents?" question raised in your paper --

Why NOT mobile agents ?

The number one argument against their use seems to be security.

However, people frequently download code from the network right now -
often binaries for DOS and Mac clients, sometimes Unix binaries, but
more often sources. But even when sources are compiled and build locally,
how often does anyone actually READ the code looking for dangerous
virus like behaviour ?

In fact, most people rely on trusting code they get from a "trusted
source".

Current practice is, in fact, insecure, and is only going to grow
more insecure as use of networked services grow. An informal network
of "trusted sources" is only viable in a relatively small networked
community.

So, I would argue that the type of safety required for mobile agent
programming languages is going to be a general requirement for networked
applications on public nets, whether or not they are actually used to
program mobile agents.

I believe that such protections *ought* to be a part of the operating
system, but we don't currently have that kind of OS support, so we need
to build it into a programming language system. ( For a history of
some attempts to build that sort of support into Operating Systems, see
Henry M. Levy's "Capability-Based Computer Systems", Digital Press 1984)

If my argument is correct - that there is going to be a ubiquitous
requirement for such "safe" programming languages, then the primary
argument against mobile agent programming disappears.

I do agree that there are many cases where RPCs or Distributed Objects
are a more appropriate technology - which is why I have also argued
for building an architecture where they can all interoperate and you
can mix and match techniques.

As an example, I would mention that adding a the capabilities
for a restricted execution environment to the Python interpreter
started (at least with me) not with the intention of programming
remote agents, but with supporting distributed and cooperative
development of the Python class library. I was looking for a way
to use the WWWeb to help maintain and expand the library, and
eliminate the bottleneck of having a single "keeper" of the official
and "blessed" Library modules. Discussion of how to implement a
safe, distributed remote module import in the interpreter, showed
that the same mechanism could enable a number of other distributed
applications, including remote server agents and downloadable client
scripts. Which also resurrected an old idea that I had put off as
not practical at the time: object-oriented files, where data have
attached methods to, for example, display or decompress themselves.
This is exactly the same problem, except files replace the network
as the medium of distribution.
I would note that in a discussion on the html-wg mailing list, there
was a mention of the ISO work on the MHEG multi-media standards, which
appears to include plans for attaching scripts to multi-media objects.

[ I *won't* CC this to the html-wg list, as it's not related to HTML,
but I will CC this to www-talk, where some discussion of Sun's Java
and other client-side agents has been popping up. ]

I believe there is a converging need for these "safe scripts",
that such safe programming systems are possible and desirable,
whether or not you want mobile agents. But that once you have that
capability, the primary objection to mobile agents disappears.