Re: lynx-dev Why doesn't lynx cache HTML source?

[David Combs]

> From address@hidden Mon Nov  9 23:46:27 1998
> From: Bela Lubkin <address@hidden>
> Date: Mon, 9 Nov 1998 23:49:13 -0800

<snip>
> > rendered), but not by much, and rendering a cached document would be
> > much faster than downloading it repeatedly.  Could someone enlighten
> > me?
> 
> This issue has been discussed extensively in the past; search the
> Lynx-Dev archives for the details.  I used www.altavista.com's "advanced
> search" to search for "host:www.flora.org AND source AND cach* AND
> text:subject AND text:html", finding 59 matches.
> <snip 2 lines>
> Only that rendered output is cached.  Since Lynx has many operations
> which require it to re-parse the HTML source, many users have suggested
not "suggested", more like SCREAMED for caching (maybe just me!)
> that Lynx cache the source as well.  This usually leads to a discussion
> of pros and cons, some of which are:
> 
>   Con:
> 
>     - would add to the complexity of Lynx
Huh?

>     - caching rules are very difficult to get right

ie, "has the page changed since I last downloaded it".  At least for
MY browsing, 99% of the time I don't care what's changed in the last
TWO MINUTES or so.

>     - would add code, increasing the size of Lynx source and binary

Come now.  EVERY improvement (almost) adds to size of source and binary,
but you don't find too many of us complaining.  Most anyone using 
LYNX instead of M$ or n-scrape are using for THREE reasons: SPEED, SPEED,
and SPEED.  Many are administrators (system) and have SO MUCH WORK to 
do in their 15-hour days, that they'll do most ANYTHING to save 5 seconds
here, 3 seconds there -- when they do that operation 1000 times per day.

>     - would increase the in-core and/or on-disk storage consumed by Lynx
>       during operation

How much.  I mean, really, how much can it take to take input from
a file than from the net?

>     - duplicates functionality which is already provided by other
>       programs, i.e. web caches such as Squid -- programs which are
>       dedicated to caching functionality and thus can be expected to do
>       it better than Lynx could hope to
Hey, I am using lynx as a USER, on an ISP over which I have NO control
or even influence -- they won't even TALK to us users.

And if I had set up my own computer as a host, then you are suggesting
that I go to all the trouble of finding, compiling, and (by FAR the 
worst part of all), and having to LEARN some
other program -- just so that LYNX (the ONLY program that I run
that would involve such caching) can avoid downloading files.

Hey, it's hard enough to get LYNX to compile and work, and now
you want me to to do that for some OTHER program!


> 
>   Pro:
> 
>     - would add to the utility of Lynx
>     - greatly speed operations which require a re-parse, including '\'
>       view-source, '^V' other-DTD, '*' image-URLs, '"' soft-dquotes, '`'
>       and "'" comment-parsing, '[' pseudo-alts, '@' raw-mode, and
>       changes in assumed document character set.
>     - easier for a regular user to install than a full web proxy

I'd say that "easier" is the wrong word.  It is virtually IMPOSSIBLE
for a normal user to do that.  My own head is SO cluttered with 
different stuff, that it is often in "thrashing mode".  Not myself
being a "real" admin ('tho that is what I am required to be, as the
only user on this sparcstation), you tell me how many classes would I
have to go to, and pay for, and take the time and brain-space (scarce!)
for, to learn to install AND MAINTAIN AND MANAGE such a thing.

NO THANKS!

>     - persistence of cache can be better tuned to the user (e.g., cached
>       objects can persist only for the duration of a session, thus not
>       consume disk space while Lynx not running)
> 
> Possile techniques have been discussed.  But the bottom line is that
> Lynx is a cooperative volunteer effort, and big projects like a revamped
> caching system do not happen unless someone contributes the code.
> 
> Please feel free to jump in and write it!  ;-}

I would if I could.