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

[Vlad Harchev]

On Fri, 7 Apr 2000, Philip Webb wrote:

> 000407 Klaus Weide wrote:
> > On Fri, 7 Apr 2000, Vlad Harchev wrote:
> >> Could anybody comment on this?
> 
> i was going to comment last night, but found a bug in some of my cells ...
> 
> >> Lynx  > c dev14  doesn't cache documents when downloading 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.
> 
> i disagree: source cache should reflect exactly the rendered document.
> if the user interrupts it or there was some problem in transmission,
> the user will usually be aware of that state of affairs
> & can send off for a complete version if s/he needs it (but see 1a below).

  That is my opinion too.
 
> i also don't like undocumented geheime IMO-Diktaten.

  Seems Klaus documents everything in Changelog.
  
> >> it would be useful to add a lynx.cfg setting like -- snip --
> 
> NO! not another piece of cfg-bloat!

  I disagree - let's make this controlable.

> >> it can be considered loss of control: even if user interrupted downloading,
> >> they deserved the right to see the source of _that_ document,
> >> not to get new behaviour with old behaviour: user just has to do ^R.
> 
> exactly, but see 1a.
> 
> > There are  3  simple choices of behavior when a loading-in-progress
> > that creates a source cache entry is interrupted:
> 
> actually,  4 .
> 
> > 1) Treat stuff downloaded up to this point as valid cache contents.
> 
> yes, tho' ...
> 
>   1a) Ditto, except when there's an existing cache entry (as 3),
>       when that entry is retained.
> 
> ... that may be better (1 & 1a are not mutually exclusive).
> 
> > 2) Drop the incomplete source cache entry, the document is shown incomplete,
> >    it now has no source cache entry associated with it.
> 
> no, as above.
> 
> > 3) Ditto, 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: that was the intention.
> 
> no, do (1a) instead.
>  
> > But is CacheThru_abort (rather than CacheThru_free) called
> > only 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 be it: the user should retain the old complete cache if it exists,
> but get the new incomplete one otherwise, however the interruption occurred.
> after all, s/he may need to examine something near the beginning,
> when the incomplete version is adequate.
> HOW the interruption occurred is irrelevant to user needs.

   Yes, exactly.
 
> > I definitely don't want to see the old behavior restored unconditionally.
> 
> let's not worry about whatever the old behaviour was:
> let's get the new one right for typical users,
> without some unannounced IMO doing their thinking for them.

   May be it would still be better to provide lynx.cfg option to allow
selecting either of 4 options above since there is no consenus:

SOURCE_CACHE_FOR_INTERUPTED:
        values are:
OK             variant 1
PREVIOUS_OR_OK variant 1a
DROP            variant 2
PREVIOUS_OR_DROP variant 3

 As for default, I propose PREVIOUS_OR_OK.

 What do you think? 


> -- 
> ========================,,============================================
> SUPPORT     ___________//___,  Philip Webb : address@hidden
> ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
> TRANSIT    `-O----------O---'  University of Toronto
> 

 Best regards,
  -Vlad