Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_INCOMPLETE

[Klaus Weide]

On Fri, 7 Apr 2000, Vlad Harchev wrote:
> On Thu, 6 Apr 2000, Vlad Harchev wrote:
> >  I researched strange behaviour of SOURCE_CACHE. It turned out that I just
> > interupted downloading every time I was testing (to save time), and lynx
> > starting from some verion younger than dev14 doesn't cache documents 
> > downloading of which was interupted (CacheThru_abort is responsible for 
> > this). 

Yes, that was part of my changes.  An incomplete document shouldn't
appear as a valid source cache entry, IMO.

> >  From logical POV, new behaviour is more correct than previous for most 
> > users.
> >  But I think it would be useful to add a lynx.cfg setting like 
> >  SOURCE_CACHE_FOR_INCOMPLETE or something like this - otherwise the change

I'm expecting Henry to speak up for making this (if implemented) a sub-option
of SOURCE_CACHE.  Which would be nicer also I*M*O.

> >  of behaviour can be considered as "loss of control" (even if user 
> > interrupted
> >  downloading file, they deserved the right to see the source of _that_
> >  document, not new copy that will be fetched - and to get new behaviour with
> >  old behaviour user just has to do ^R).
> > 
> >  Currently lynx don't cache incomplete document independant of the
> > "cache-control" and "expires" headers.

>  Could anybody comment on this?
>  May be it would be better to restore the old behaviour unconditionally? 

There are three simple choices of behavior in this situation (when
a loading-in-progress that creates a source cache entry is interrupted):
1) Treat stuff downloaded up to this point as valid cache contents.
2) Drop the incomplete source cache entry, the document is shown
   incomplete, it now has no source cache entry associated with it.
3) Drop the incomplete source cache entry, the document is shown
   incomplete, but if it had previously been loaded (completely) and
   already had an old source cache entry, that old source cache entry
   remains associated with it.
It's actually 3) that is implemented (AFAICS now :) - at least that
was the intention).

The difference between what happens when loading finishes normally, vs.
what happens when loading is interrupted, is implemented in CacheThru_free
vs. CacheThru_abort.  As you can see, it's not that much, and nicely in
one place.

But is CacheThru_abort (rather than CacheThru_free) only called if
the user presses 'z'?  What about other abnormal terminations, such
as network connection errors?  Even if they don't currently (all?)
get signalled as _abort() calls, shouldn't they?  So we should not
assume that _abort always means an intentional interrupt that the
user wants.

So I definitely don't want to see the old behavior restored
unconditionally.

   Klaus