> > MYTH #3: The Web is not an object system.
> Of course it is. But I'm still struggling with the different
> intuitions about what kind of object system it is, and can be.
> Sorry to be a pest about it.
[Rohit's section]
You can view the object system as above or below HTTP. At the lower level, we
have a DII server interface. Objects have handles (http: URLs), and the
interface is responsible for marshalling requests and replies. Unfortunately,
there is no built-in typing, much less metainformation for marshalling, so we
have a barn-door situation here. But HTTP *can* invoke any new method with
some arbitrary argument data upon the "resource" behind some url. And, we can
reverse-engineer appropriate typing and marshalling formats (viz. the weak
precedent of HTML and FORMs)
Above HTTP, we have a document transfer system which we can build an object
system on top of (imagine building one on top of FTP just as well). We have
resources whose only observable shadows are MIME entities. We can fetch, copy,
or move snapshots of those entities, or send structured entites which trigger
remote events on reciept (form posting).
This should make it clear that in either case, HTTP is mainly a wide-open
messaging system with synchronous transactions; HTML/XML is a wide-open
marshalling format without typing (although the XML-Data note makes enormous
strides!); and http: URLs are imperfect handles where many may map to the same
object; and the object replicas are not known to the naming layer.
We wrote:
> > MYTH #1: The Web (as programmable platform) succeeded because of CGI.
> > TRUTH: Forms are relevant, not CGI. HTML FORMs are the real contribution
> > of the Web to software module interconnection.
[Dave: again, you know better, *of course* these are opinions. It wouldn't be
any fun to back down from calling it God's Given Truth, though.]
> Now I will be the first the admin that CGI, well, sucks. Its slow,
> but its reasonbly platform-independant to implement. But, before
> there was CGI, THERE WERE NO FORMS. Its like saying the sun is not
> revelant but the light that gets to our planet is. Now I know there
> are lots of non-CGI programming methods of processing forms now, but
> back in the primordial muck that was the web no FORMS, no CGI.
Don't jump to conclusions in rationlizing the history of technology. The very
first 'killer' web application was the CERN phone book: a purely
program-generated data delivery service. The 'scripted page generation' aspect
of CGI was indeed developed before POSTing FORMs. At the same time, the
primordial <ISINDEX> tag already restablished a parameter-passing remote
invocation service; in this case, of a single search string parameter (we were
competing with gopher, remember?). The *Common* Gateway Interface emerged
*after* experimenting with FORMs. Remember why the mime-type is
x-www-form-urlencoded? Because in the beginnning, FORM arguments were tacked
onto the end of the URL; try ACTION=GET sometime. Only when the URLs got too
long with all those arguments stuffed in did we cheat by thunking the tail of
the URL into a POST body. And then, after a few brief generations of custom
parsing libraries, NCSA httpd decided to preparse them into UNIX environemnt
variables.
History isn't neat. Intent is even messier. I worked with the Web early enough
on, and with some interesting enough folks, to stand my ground on intent,
though.
[Adam's section -- he gets credit for the research!]
Dave Crook continued:
> BTW, I
> have always thought of forms as being a clunky interface. The kind of
> thing that a programmer just threw together because it seemed like a
> good model for data input rather than something that was purposly done
> that way for design's sake. Why elevate them in such a degree?
The point is that declarative UIs are important. They take the
data-centricity that exists in the current, clunky FORMs, and allow us
to make more sophisticated queries of the data:
http://xent.ics.uci.edu/FoRK-archive/jan98/0256.html
What we'd like is argument typing.
> > MYTH #2: Transport mechanisms are relevant.
> Sorry Adam, I do have to jump on you on this one. Here, try this
> truism on for size "No Transport mechanism, no communication". That
> to me implies that the the mechanism itself will have some effect on
> the communication itself.
The point is, I shouldn't have to think about whether I'm using TCP, or
UDP, or multicast. As a developer, I should be able to just give my
service requirements and let the middleware layer pick the appropriate
transport mechanism. By and large, the bit-channel does NOT. Where it does, it
isn't a transparent thing to be patched in by PEP-like composition: HTTP for
lossy multicast becomes RTSP, not HTTP-with-unreilable-semantics.
This goes further than choice of bit-delivery, by the by. When to push a
message out to a recipient point-to-point (ftp; synchronous push), when via
transactional relays (mail; asynchronous push), when to leave it on the server
to be polled on-demand (http; synchronous pull), when to broadcast it to
relays to be polled on demand (news; asynchronous pull) -- these are also, in
large measure, irrelevant to the application designer. Instead, they are
relevant to the *user*, and ought to be chosen dynamically based on priority,
cost, and resources. People pay a LOT of money for message queues to do
precisely this.
> > MYTH #3: The Web is not an object system.
> Last time I checked, the thing we call the web is just a system for
> displaying a few tech papers that got WAY out of hand. We could be
> doing all of our web pages in LATEX or nroff (shudder) if the guys over
> at cern didn't make up a watered down SGML version for displaying a few
> documents on unix systems. I dare you to tell me they envisioned "an
> object system" when they made up http.
Challenge taken. Look at
http://www.w3.org/DesignIssues/
Specifically, look at
http://www.w3.org/Talks/CompSem93/FutureText.html#z2
which was written by Tim Berners-Lee in 1993:
| Object-Oriented distributed databases and the web appraoch each other
| also. providing object-oriented featues in the web will allow users to
| manipulate objects other than documents. Examples of this may be
| scientific data, and simulated worlds, in wich multiple users define,
| and interact with, objects of all conveivable kinds.
|
| ...
|
| The HTTP protocol was enhanced in early 1993 to allow many of these
| features to be incorprated, including multimedia with format
| negotiation, authentication, more infromation about the client being
| available to the server, more feedback to information providers, and
| data entry by users.
Then have a look at HTTP-NG's activity statement at
http://www.w3.org/Protocols/HTTP-NG/Activity.html
Specifically,
| The purpose of the other half of the Project is to design and build a
| prototype and test the hyphothesis: "Can a generic distributed object
| system be used as the foundation of the Web?". An example of an
| architecture which might be useful is a layering model consisting of the
| following three layers:
| Transport Issues
| Object-oriented RPC
| Web Interfaces
Finally, go to the "classic HTTP documents"
http://www.w3.org/Protocols/Classic.html
where you'll find the original HTTP design issues
http://www.w3.org/Protocols/DesignIssues.html
which were later debated in
http://www.ansa.co.uk/ANSA/ISF/WWW5/DOWpanel.html
| Object technology is the perfect way to support new Web media types: the
| browser can transparently and automatically download the digitally
| signed component that interprets them. Digital signatures allow the
| downloaded component, if it comes from a trusted source, to do things
| that might not be safe to permit code you couldn't trust.
|
| Invent new "media types" for application specific protocols. The
| component for the new "media type" can be the client-side part of the
| protocol. Programming the protocol can be done using distributed object
| technology. The distributed object technology can even be the
| transparent remoting of the object technology used by the browser's
| extensibility mechanisms.
|
| HTTP in many ways appears quite object-like. It has resources which have
| methods. However, its (implicit) type structure is richer and looser
| than that of most object-oriented systems. The reason for this is to
| allow for evolution and intermediaries. New headers (arguments) can be
| added to HTTP messages, and new parameters to existing headers, without
| breaking backwards compatibility, because they are restricted to be ones
| that can be ignored by the recipient if not understood.
Off to breakfast,
Rohit
(Adam)