lynx-dev about downloading and source cache (was: THANKS AND QUESTION)

[Klaus Weide]

On Tue, 4 Jan 2000, Larry W. Virden wrote:
> On Mon, Jan 03, 2000 at 06:19:47PM -0600, Klaus Weide wrote:
> > 'D'ownload means "download", period.  It's always meant that.
> > The user can expect that a new download attempt will be made,
> > rather than just using a (possibly corrupt) cached copy.
> 
> Assuming that lynx continues in this fashion - where download _means_ 
> download -
> will the downloaded version replace the cached version as well?  That way,
> the possibly corrupt cached copy gets refreshed...

No, that's not happening - in order to be "seen" by the cachewriter part
at all, an incoming document stream has to be HTML, being parsed as such.
Just another effect of the whole thing being designed as a narrow-purpose
"cache for a current document's HTML source", not a general purpose caching
mechanism.

(Well, your question was phrased in the future tense - I can't really
answer that, just describe what is the case now.)

Loading-for-rendering and 'd'own-loading are oblivious of each other.
One uses and (possibly) (re-)generates a souce_cache entry.  The other
does neither.

Assume you have instance A of document x.html in the source_cache, and
rendered as current document.  You can now switch back and forth between
normal and source view, or use various keys that cause re-rendering like
'@', '^V', '*', '`', etc., or even make (some of the) changes in the
'O'. Menu, and you'll always use instance A.  Go to history page (or
somewhere else where there's a link to x.html) and use 'd' there, and
you'll get a new instance B of x.html.  Return to where you were and
resume flipping '\', '^V', etc., and your're back to using instance A.
It seems to me that this is what one would expect, isn't it?  And that
it is in line with source_cache's apparent behavior in general?
(Of course, in the most "regular" case instance A and B will have
identical contents, so it doesn't matter.)


You *can* now force replacement of a corrupt cached copy with ^R,
at least.  (As long as you're viewing a rendered HTML document,
not in source view.)  That didn't work right before dev.17.

Also, undetected corruption is now less likely, at least for
easily detectable reasons: write failure, user interruption.
(Network socket read errors, broken proxies, etc., may still
cause undetected corruption.)

   Klaus