>I [Ken] wrote:
>> >We really need to think about who in the industry is in the best
>> >position to implement/control monolithic standards and monolithic browsers.
>> >It isn't CERN, NCSA or the community of Web hackers, that's for sure!
>and Chris Lilley replied:
> I would like to see some support for this rather airy dismissal.
>The point I was trying to make is that as software gets more and more
>difficult to build (i.e. it's complexity increases) fewer and fewer people
>are willing to expend the effort required to build it. There are a number of
>examples of really, really good freely available software. Some examples of
>these systems are the X Window System, Linux, Net/Free/386-BSD, GNU emacs,
>the Andrew User Interface System, Tcl/Tk and TeX/LaTeX. However, these
>systems are still the exception --- I think that it's safe to say that it
>would be extremely difficult to initiate a project of similar scale.
Actually I would say that the various web servers - CERN, NCSA, Plexus, gn, Mac
HTTP - and the browsers - NeXT, the three Mosaics, Chimera, Cello, W3emacs, plus
Dave Raggetts and Phil Hallam Bakers testbed ones - plus the assorted CGI
scripts and other nifty gateways and stuff - plus the various editors either
available now or in progress - plus maintenence tools like MOMspider - plus the
other robots and other indexing tools - collectively correspond to a "project of
similar scale" already.
The trick is to have an interface specification so that people can implement
small bits without having to wory about all the other bits.
If I want to link to a new-and-wizzy format that holds, say, five channels of
floating point colour data from a satellite I just need to implement a viewer
for that type and declare a MIME type. Everything else works fine with it.
If I want to make my server use an automated English-to-French translator on all
files before sending them to clients in .fr domain, again there are selected
bits of the server to alter, I don't need to re implement the whole thing from
scratch.
Chimera extends this idea by devolving _all_graphics rendering onto external
apps. So to do an inline GIF, have the GIF viewer render into a pixmap or an
area of the main window that you give it. Suddenly, having any type of graphics
inline becomes possible without additional effort.
So the ideal is to have a flock of communicating applets, all providing some
service or other, and the browser as such is just the glue that synchronises and
coordinates this flock. Any applet can be enhanced without impacting the others.
I believe Dave Raggetts browser is designed this way.
> >The
> >only people in a position to implement a monolithic browser are those with
> >dedicated (and large) programming staffs --- such as Framemaker or Microsoft.
OK then, I will agree with you. But the last thing we want is a monolithic
browser, so that ceases to be a problem.
It also removes the problem that once some large monolithic company got hold of
the Web the first thing they would do would be to introduce subtle
incompatibilities so that their payware version gave you an advantage, and so
you were locked into their 6 monthly upgrade payment cycle. This is just based
on past experience of companies like these. Ask anyone how well the RTF standard
fares each time Microsoft upgrade their products. Its just easier, all round, to
only use Microsoft products - use Word to generate it, use their help compiler
to process it. So simple, all you have to do is pay them and trust them. No
thanks.
One of the stongest consensuses (consensi??) to come out of WWW94 was the
universal dread of what would happen when Microsoft noticed the Web. To be fair,
I think that particular company was being used as an archetype of the general
class of commercial companies.
> The situation changes radically as software becomes simpler. If you look at
> text editors or small languages the number and variety of free applications
> is enormous.
I agree completely, which is why the current situation of Web design by
consensus among people interested in the Web is the best bet. Hardly a week goes
by without some new, small improvement in one area or another. As the interfaces
become better defined, this process will accelerate. Hey folks, I knocked up an
improved HTML 3.0 table renderer, works with all compliant browsers. Do you see
some huge corporation coming out with statements like that? No.
<aside>
For a laugh, try telling Frame (just to show I am not singling out Microsoft
unduly) that you really need multi page footnote handling and could they
implement it soon please. If you need to understand this joke, try scanning the
framers list and see how far back those requests have been coming.)
</aside>
>If I apply this reasoning to HTML+, then there must be some point at which a
>browser becomes so complex that very few people are willing (or able?) to
>implement one.
Implement one, no. Implement bits, yes.
>Web browsers
>will start to look an awful lot like desktop-publishing applications.
Yup.
> How
>many freely available desktop publishing tools do you know?
None worth a damn. Yet.
>Who dominates the desktop-publishing market? How easy is it to make a
>desktop-publishing application?
How easy is it to get them to respond to user demands? How many users are locked
into proprietary solutions and forced to pay top whack because the cost of
moving to another proprietary solution is too great?
>Who controls the desktop-publishing document format standard?
Which standard was that, again?
The point about the increasing complexity of the raft of software collectively
implementing the Web is well taken. But the solutions are already in hand, using
the long established software engineering practice of modularity.
-- Chris Lilley +-----------------------------------------------------------------------------+ | Technical Author, ITTI Computer Graphics and Visualisation Training Project | +-----------------------------------------------------------------------------+ | Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc | | Oxford Road, | Voice: +44 61 275 6045 | | Manchester, UK. M13 9PL | Fax: +44 61 275 6040 | | X400: /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/ | | <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +-----------------------------------------------------------------------------+