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

[Bela Lubkin]

Nelson Henry Eric wrote:

> The one problem I have is that with the antiquated hardware I have, memory
> management is VERY poor; the cache would have to be on disk for me or my
> users to make use of it.

With the design I'm envisioning, you would have the following options:

  - compile with the source-cache disabled (same behavior as today)

  - run with the source-cache disabled (same as today except a bit more
    code in core)

  - enable the source-cache, but make it very small

You could probably use the 3rd option.  In fact, you may not know that
Lynx's default behavior is to cache 10 rendered documents.  This is
controlled by DEFAULT_CACHE_SIZE in lynx.cfg.  If your memory is so
small, you could probably reduce that to (say) 5.  Or if the
source-cache existed, you could reduce it to 5, meaning "cache in
parallel both the source & rendered versions of 5 recent documents" --
should take similar amount of memory to the current 10 rendered
documents.

> > 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,
> 
> Is that really a *source* page, or is it a _rendered_ version of the
> source?  What I see on the screen is all lines cut off at 80 characters,
> so I question if it is _raw_ source as one would get by d)ownloading.

It's a rendered version of the source.  The only way to get raw source
is to download it.  Another way to put this point: Lynx isn't a file
viewer.  Even with a totally normal "text" file, a mild rendering is
applied (among other things, it truncates long lines).  The '\' command
just shows you how Lynx would have rendered that source if it thought it
was text/plain rather than text/html.

> > 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).
> 
> Exactly.  (Seems to add a lot of complexity.)

Some complexity.  I don't think it's too much.

>Bela<