W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1998

Client modules: Was: RE: Client side : an economic perspective

From: William F. Hammond <hammond@csc.albany.edu>
Date: Sat, 11 Apr 1998 11:45:09 -0400 (EDT)
Message-Id: <199804111545.LAA24780@hilbert.math.albany.edu>
To: sp249@cam.ac.uk
Cc: martin@net.lut.ac.uk, waconigl@mccallie.org, www-talk@w3.org
Stephanos Piperoglou <sp249@cam.ac.uk> writes in reply to
Andy Coniglio <waconigl@mccallie.org> and others on
Sat, 11 Apr 1998 02:29:14 +0100 (BST):

:  . . .         Consider what would be needed to build from scratch, say
: (off the top of my head, not that I'm actually considering this or written
: any code :-)) to write a browser that can compete with the Big Two:
: 
: - An HTTP 1.1 agent
: - An FTP, gopher and (at least) simple mailer or OS Mail API interface
: - A text-to-DOM translator that will deal
: - Around a million little catches in the above to observe backward
: compatibility or "feature" propagation
: - A stylesheet mechanism with rendering on screen and paper
: - A Java VM (small task? Nooope) that reads the DOM
: - A scripting mechanism (or two) that reads the DOM
: - Incremental rendering and processing by client-side methods (a nightmare!)
: - A "plugin" mechanism to facilitate expansion of supported mime types
: - Builtin plugins for several mime types (image/* and a few others)

Under present practice, for the most part, these separate modules are
integrated at the source code level.  The user who does not like one
of the modules is stuck.  (Nevertheless, truly clueless users need these
big shrink-wrapped things.)

I would like to see more development where these modules are integrated
as independent free-standing processes so that savvy users can specify
substitutes for the default modules.

Some of these modules need to be able to talk to each other.  For
example, the HTTP/1.1 client and the HTML-screen-renderer (which is a
required module) need two-way communication.  On the other hand, the
mail module just needs to be launched, and that is fortunate, because
I prefer to use the mailer that I've been using since before HTTP/0
was even a gleam.

: 
: Are we done yet? Try implementing THAT on a wristwatch.
: 

For example, a user might want a very special HTML-screen-renderer
with a 100x50 wristwatch screen.  (You're not worried about memory or
file system.)

About a month ago Martin Hamilton <martin@net.lut.ac.uk> wrote:

} Date: Mon, 16 Mar 1998 21:01:45 +0000
} Subject: The Cathedral and the Bazaar
} Resent-From: www-talk@w3.org
} X-Mailing-List: <www-talk@w3.org> archive/latest/3810
} 
} I think many people here will already be familiar with this :-
} 
} <URL:http://www.redhat.com/redhat/cathedral-bazaar/cathedral-bazaar.html>
} 
} Amongst other things, Netscape cite it as the reason (or one of their
} reasons ;-) for their decision to release source :-
} 
} <URL:http://www.mozilla.org/mission.html>

I think that process-level integration of modules, as opposed to
source-code-level integration of modules will accelerate the
benefits of the bazaar development model.

                                   -- Bill Hammond
Received on Saturday, 11 April 1998 11:45:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:23 GMT