Opendoc had its chance, and it flubbed it. There's a new sheriff in town.
See, maybe Opendoc is too much. Its transport mechanism is a mess.
IIOP is a mess: it's too big, it's slow, and it's a sledgehammer when a
flyswatter will do. No, I'm convinced that a simpler, extensible system
would be a better basis for a distributed file system (or a distributed
ANYTHING for that matter).
Rohit and I have been flirting with this idea for a while; remember 18
months ago, Gordon, when you came to visit us and we drew up all those
charts, and Ernie concluded that *TP is doable? Well, maybe the next
generation of HTTP *should* be *TP, by stripping it down to a core set of
functions (i.e., just GET and PUT), and by giving a method by which the
protocol can be extended.
I get the feeling that keeping HTTP as a transaction system has benefits
that outweigh those that arise from moving to an RPC-based system. And
by shrinking the current HTTP, as opposed to growing it, we give an
ideal minimum standard on which to build a distributed anything, because
in such a system,
>>> THE MEDIUM IS THE MESSAGE. <<<
Messages form the foundation of any distributed system, and so the
smallest, most extensible transport layer that allows for this, is
the holy grail for which to search. And I'm not talking about a
mailbox system built on top of Java sockets; I'm talking about an
actual, bare-bones, living-on-the-wire, efficient, universal
middleware layer.
See, Tim, the problem with Opendoc is that it's too big to be an
efficient, and therefore ideal, component architecture. In an ideal
ICA, each component has a name and provides a service, and each
component has a state (and the component and its state can be
marshalled/demarshalled). And that's ALL there is to each component.
If HTTP were to evolve into a *TP -- the universal transport protocol
that subsumes all existing transfer protocols -- it would need to be
small (providing only GET and PUT, say) but extensible (using a
mechanism like a Protocol Extension Protocol).
When I say extensible, I mean extensible in the sense of how state is
transferred by *TP. Maybe it happens by explicit request (like the
current HTTP). Maybe it happens by explicit push (like SMTP). Maybe it
happens by timed flood fill (like NNTP). Another issue is whether the
transferred bits are moved (SMTP), or actually copied (NNTP, FTP, HTTP).
Other issues include but are not limited to reliability of transactions,
security of transactions, and timeout conventions. The point is,
though, that NONE of these issues have to be part of the *TP. They are
extensions, and PEP can handle adding these extensions. The universal
transport protocol should be simple, small, a core, a microkernel.
The additions give the power, but at the base is a fast, automatable
transaction system.
And automatable transactions are the key win here, according to my
friends Captain Morgan and Jim Beam, who visited me last night to
show me the KillerApp of coreHTTP + PEP. Unfortunately, I was too
drunk to write coherently, and the idea doesn't seem so killer under
the envelope of sobriety, but think about it: what if you had a
secure, automatable transaction system? And by automatable I mean
that components can be plugged into each other through interactions
with each other's interfaces, automatically by a computer. For
example, I could drag and drop my business card into a form, and
all the proper information would trickle down to the appropriate
form fields automatically.
Okay, I have a secure (thanks to PEP), automatable transaction system
(thanks to coreHTTP). What can I do with it?
Darn, I wish I could read my drunken handwriting. It looks like I wrote
something that has to do with payments. Not micropayments though.
Instead: Actual, currently existing, vendor-customer macropayments.
So here's the KillerApp: Build coreHTTP and PEP, and then build an
automatable macropayment system that serves as a third party between the
customers and the vendors, in the way that credit card companies serve
as the third party between the customers and the vendors now. However,
because our KillerApp lives in the digital world, we get the benefit of
automatability: sensitive info like credit card numbers need not be
transferred over the wire, because the wire itself handles automatically
the verification of the transaction, and commits the transaction
seamlessly.
In other words, just by visiting the spot, the customer brings along all
the information associated with her/him. When s/he clicks to buy
something, this information is used *automatically* to determine if the
transaction should be committed (if sufficient funds or sufficient
credit exists) or aborted (if funding/credit information cannot be
verified). Automatability also gives us the ability to DISCOVER new
interfaces -- for example, if someone wants to barter instead of
transferring funds for a service, the macropayment system can
automatically adapt to the alternate request to barter. By minimizing
the type system to the bag-of-bits plus black box, we allow all kinds of
extensions that CORBA gets crushed on (because it has to build
everything up from primitive types, feh on it).
Automatic macropayments are useful for everything from bank fund
transferring to actual purchasing of goods and services. (The beautiful
part here, Rohit, is that an "automatic macropayment" *is* a session.)
What's the benefit to the customer? The security gives her/him piece of
mind: s/he need not transfer sensitive pieces of information over the
wire, because automatability allows a "verified payment" to be filled
into the form on the vendor's end without ever sending a credit card
number over the wire. Instead, both the customer and the vendor confirm
a "verified payment" through a third party -- and here's the important
part -- automatically.
There's another benefit to the customer, in the form of recordable,
verifiable transactions: the customer can maintain a list of purchases,
updates, and so on, automatically: recordkeeping is done on-the-fly.
Records are customizable, indexable, searchable, queryable, filterable,
and come tax day, automatically pushed onto the tax forms in the way
that most appeals to the record holder.
What's the benefit to the vendors? Same thing as the customers:
automatic verifications, automatic fund transfers without actually
sending any funds or other sensitive information over the wire, and
automatic record-keeping. All done through the familiar transaction
system instead of the cumbersome RPC-after-RPC-after-RPC.
What's the benefit to the company that writes the third party
transaction system? Well, first, they're building on top of open
standards (coreHTTP and PEP) which means that all the different
component players (Microsoft, Netscape, Sun, Lotus) can build layers
that interface with the system. The Internet then becomes one humungous
transfer system of funds, goods, and services, from anywhere to
anywhere. After the system is built, you can sell out to Netscape or
Microsoft, or build an empire with it yourself. Whatever you like.
That is not to say that the Internet isn't getting to be one humungous
transfer system anyway, but that this vision (build it on top of
coreHTTP and PEP) is The Best Way to solve the problem of designing such
a distributed transaction system. Because our way IS automatable,
whereas DCOM is not, CORBA is definitely not, and HTTP with RPCs isn't,
either.
Ah, but we're at a crossroads. HTTP has to make the conceptual leap
from being a document transfer protocol to a universal component
transfer protocol. This is more of a philosophical leap than a
technological leap; indeed, all the technology to do this was already in
place when TimBL invented the Web! (As per the subject line of this
email, we can BLAME the Web on Andreeeeessseen, but we can MERIT the Web
on TimBL).
But to recognize the fact that everything in cyberspace is a DOT
(Document/Object/Type), with hyperlinks being the shortest distance
between two DOTs, is nothing short of nirvana. The enlightened move on
to the next level, while everyone else sits around scratching their
heads, saying that there's nothing to this vision or it's obvious or
it's stupid or it doesn't raise the bar at all. Well, I'm telling you
it DOES raise the bar; the only thing in question is my ability to relay
the implications in such a way that people Get It. Or maybe I don't
*want* everyone to Get It until after I'm done with my KillerApp.
8) 8) 8) Adam
----
adam@cs.caltech.edu
The psychiatrist said it was an excellent session. He even gave me this
jaw restraint so I won't bite things when I am startled.