Re: The Web Vs. Objects; Trust Management paper on First Monday.

I Find Karma (adam@cs.caltech.edu)
Tue, 16 Jun 1998 07:32:07 -0700

> My point was that if we are going to be object-oriented on the web, we
> need to really be object oriented, and that means that we *must* move
> code around. Java shows us one way of doing this, but it is hardly the
> only way; but any way has to be both portable and secure. This is not,
> by the way, the party line...while applets are like this, most other
> Java APIs don't make use of the dynamic and mobile nature of Java.
> Right now, the Web is object oriented in a clumsy way, moving around
> indications of what code is needed (generally via Mime types) but
> requiring the code to be moved by hand. The point I was trying to make
> is that we need to find a way of allowing the code to be moved as
> easily as the data if we really want to have objects on the web
> (and, by the way, we really do want to have objects on the web).

In all seriousness, for those of us who missed COOTS98, could you kindly
explain (or provide a pointer to an explanation of) why "we really do
want to have objects on the Web" that are sent from Web servers to run
on the client machines?

I mean, as opposed to having the Web simply be a substrate for the
transportation of documents -- the artifacts that represent the states
of nonmoving objects at given points in time...

Is this just because sometimes it's more efficient? (For example, I can
send an object that computes Pi to 17 quadrillion digits -- and then
have that object compute them -- faster than I can send 17 quadrillion
digits.) Or are there other compelling reasons, too?

Also, would you agree that we will need some kind of trust management
infrastructure in place in clients, proxies, and servers, before we can
have the security we'll require from such mobile code? Speaking of
which, a rewritten, toned-down version of the Khare/Rifkin survey of
Trust Management on the World Wide Web appears in the June 1998 issue of
First Monday:

http://www.firstmonday.dk/issues/issue3_6/khare/index.html

----
adam@cs.caltech.edu

THE SOFTWARE DEVELOPMENT PROCESS
1) Order the T-shirts for the Development team
2) Announce availability
3) Write the code
4) Write the manual
5) Hire a Product Manager
6) Spec the software
(writing the specs after the code helps to ensure that the
software meets the specifications)
7) Ship
8) Test (the customers are a big help here)
9) Identify bugs as potential enhancements
10) Announce the upgrade program