Re: www & objects

William F. Hammond (
Sat, 9 Dec 1995 16:24:29 -0500 (EST)

Sankar Virdhagriswaran writes in "www-talk":

> Date: Sat, 09 Dec 1995 13:39:07 +0000
> From: "Sankar Virdhagriswaran, Crystaliz Inc."
> <>
> Subject: www & objects - was OLE/COM - Microsoft's Strategy For Once Again
> Dominating The Software Industry
> X-Sender:
> To: "Daniel W. Connolly" <>
> Cc:
> Resent-From:
. . .
> IMHO, Mark asks the right questions. The first and most important question
> to answer is what *new* applications will be enabled by making Web object
> ready/object capable/etc.
. . .

New applications aside, the lack of object design in what most of us
are using today -- mainly the ubiquity of all-in-one browsers as
opposed to separate components -- means that what we can do today
cannot always be done with grace and flexibility.

As things are, if an information provider wishes to offer something as
basic as a PostScript document [mimetype="application/postscript"] it
becomes an important question what will be the serving protocol: for
example, gopher or http.

It <blink>should not</blink> be an important question.

But it is an important question because seamless retrieval for screen
viewing will be possible only by an information seeker using a browser
that is tuned specifically to the serving protocol. Most extant
gopher browsers cannot seamlessly retrieve for viewing a PostScript
document from an http site, and most extant http browsers cannot
seamlessly retrieve for viewing a PostScript document from a gopher

Another example of browser-centric lack of object design: most present
browsers cannot be <em>started</em> at a URL pointing to the
mimetype "application/postscript".

In an object-oriented set-up some information seeking users would
prefer all-in-one browsers but those who prefer separate-component
stereo systems at home would have the option of running a
"browsing-master" application that oversees a user-configured list
of "do-protocol" applications (one for ftp, one for gopher, one for
http, one for nntp, ...) and a user-configured list of applications
for viewing (and printing, downloading, ...) mimetypes.

Of course, a standard for inter-process communication is needed
(please, ultimately not something like the "X resource database" which
(a) really belongs to the user and not to the client and (b) is GUI
specific). The IPC standard needs to be public and universal so that
browsing-masters, do-protocol-ers, and anchor-capable-viewers (like
"xhdvi") can be mixed and matched.

For that matter it would also be good to have all-in-one browsers that
did everything by default (well, certainly not every mimetype) so long
as they gave fussy users the opportunity to invoke do-protocol
applications for some protocols and mimetype-specific applications as

William F. Hammond Dept. of Mathematics & Statistics
518-442-4625 The University at Albany Albany, NY 12222 (U.S.A.) FAX: 518-442-4731