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

[Leonid Pauzner]

10-Nov-98 14:33 Bela Lubkin wrote:

> In past discussions I have advocated a Lynx internal cache which would
> hold many documents (user-settable), for arbitrary lengths of time --
> perhaps even across invocations of Lynx.  As, for instance, Netscape
> has.  Such a cache would have considerable benefits beyond the simple
> 1-document cache; but it would certainly require full, correct caching
> semantics.

> Even the simple 1-document cache has to interact with some caching
Really? Doesn't it enough to introduce one global flag in mainloop -
"reload internally" vs "reload as usual"?

> rules.  There have been bugs in the past relating to Lynx's current
> 1-document-in-1-rendering "cache", which is just about as simple as it
> can possibly get.

1-document cache may be a first shoot:
probably kludge it to incoming socket stream
and check the cache somewhere before DNS search -
this is not the best way for speed (to use a complete internal circle
instead of Klaus's "internal link") but easy and clear.

>> >     - 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?

> Space to store that file on disk, or in memory.  Since there is no
> natural limit on the size of an HTML source file, that could be
> arbitrarily large.  (If the cache fails on files above a set size, I'm
> sure you'll be back in a week complaining that you found a bigger
> one...)

Roughly speaking, caching the sources will takes the same memory
as rendered documents takes, so we got a factor 2 or something like this.
And disk space for cache should be defined explicitely.