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

[Bela Lubkin]

T.E.Dickey wrote:

> > temporarily saving away or caching one file is less hard on resources 
> > than running a local proxy. 
> >  
> > > (2) should Lynx cache JUST THOSE source files obtained by  \ ? 
> > >    -- some of us believe this would indeed be very useful 
> > >    when trying to track down what's wrong with someone's bad HTML 
> > >    & would not happen often enough to overload anyone's system. 
> >  
> > Indeed, that would also avoid loading again the file when toggling 
> > with '\' 
> and also when telling it to re-render with ^R.

and when changing image handling with '*' or '['; changing charset
options with Options or '@'; changing links-are-numbered status;
toggling renderers with ^V; toggling comment processing with ` or ';
toggling quote processing with "; have I missed anything?

For my *personal* use I would want Lynx to cache all HTML source files,
allowing any of the above re-rendering actions to complete without
having to re-retrieve the page.  I would want Lynx to use the same
algorithms it uses for caching rendered pages.  I would want to have the
option of telling it to cache *both* rendered and raw pages, to cache
only rendered pages (as it does now), or to cache only HTML source.  The
third option would make sense for a user with a fast CPU and little
memory; especially if he also had a slow pipe to the net.  The 1st
option for users with lots of memory; the 2nd for traditionalists and
for people who rarely change rendering options and can afford to spend
only a little memory.

I know that I would use all 3 options at different times and on
different machines (I use Lynx on at least a dozen machines of varying
capability and network connectivity.)

It's clear that what and how to cache is a highly personal choice, so
any changes need to be optional and configurable.  Which is fine;
configurability is one of Lynx's great strengths.

I don't think the 3 options would be difficult.  Start with the current
model.  Add parallel structures so that for each cached, rendered page,
we also have a parallel cached raw (source)  page.  Manage them in
parallel (when we're going to throw out a cached rendered page because
it's "too stale", also throw out the source).  When going to fetch a
source page because of a rendering change, check the raw page cache.
This gives option #1.

To implement option #2, put an `if' at the top of the code that caches
the raw pages.  If we're not supposed to cache them, don't.  When doing
a re-render, the "check the raw page cache" step won't find the raw
source, so it'll re-fetch.

To implement option #3, add code to free the rendered but not the raw
page when we load another.  Now if the user returns to that page, no
rendered page is found in memory.  The "check the raw page cache" step
finds the raw page, so it gets re-rendered from memory.

The rendered page cache also needs to keep track of the rendering
conditions of each page.  Currently, Lynx has only a rendered page
cache, and it doesn't keep track of what it has.  For example, go to a
site (e.g. http://sol.slcc.edu/).  Follow the first link.  Hit '\' to
see the source for that link.  Now hit left-arrow to go back to the main
page.  Now follow the first link.  You get the cached *source* page
rather than a rendered page.  For the parallel-caching model to work,
Lynx needs to have a set of flags associated with cached rendered pages,
telling it under what conditions this rendering is valid (and thus,
under what conditions it needs to re-render it, either from cached
source or by re-fetching that source).

>Bela<