lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: lynx-dev caching after \ (was why reload etc?)]


From: David Woolley
Subject: Re: address@hidden: lynx-dev caching after \ (was why reload etc?)]
Date: Fri, 10 Jul 1998 08:36:45 +0100 (BST)

> memory cache but I don't want to run extra programs to work around a
> lynx... hum ... peculiarity.

You are trying to treat Unix like Windows.  The trend in Windows is towards
supplying software which does everything under a unified interface, whereas
Unix has always had the philosophy of assembling several programs which 
each do one thing well.  (Actually there is some trend towards this with
Windows, but at the developer level - a lot of products are not much
more than the glue which holds together several components.  Even Microsoft
will use separate components; the empirical behaviour of Excel is that
it uses the MSIE cache for embedded documents, even though it seems to
have its own HTTP support - it fails, when embedded,  if the document
is uncacheable and needs authentication, which has been given by the
main browser, but works if it only needs authentication.)

The strangeness in Lynx, if anything, is that it caches at all, although
there are good reasons on slow machines given the current poor performance
of the rendering code.

One of the consequences of destroying the component concept is that the
program gets more and more difficult to maintain.  My judgement is that
it is already too complex and there is virtually no-one left with the
time to understand the program well enough to do more than local changes
to it.  It is just about possible to maintain clean inter-component interfaces
within the source code of a single program, but it needs a lot of
discipline and coordination, as it often rules out a quick change, because
it would violate the structure.  Distinct programs enforce boundaries much
more effectively.

Once you accept there is some component element, you either end up with 
the current Lynx situation, where you have multiple copies of essentially
the same logic, or the Microsoft position, where installing a new "program"
usually secretly updates third party components shared by other "programs",
or as happens too often, because of badly written installers, downdates them!

What, maybe, is needed is a Lynx source distribution, plus two binary
distributions.  The first is just the clean Lynx code and the second is
a bundle of software plus an installer which emulates the total capabilities
of the bundles of software and installers that form a typical Windows 
browser.  We already have a minimal version of the final case in the Win32
version, as it contains a sendmail etc. which would be freely selectable,
independent components on Unix.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]