lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philip Webb
Subject: Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_INCOMPLETE
Date: Fri, 7 Apr 2000 14:30:38 -0400

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).

i also don't like undocumented geheime IMO-Diktaten.
 
>> it would be useful to add a lynx.cfg setting like -- snip --

NO! not another piece of cfg-bloat!
 
>> 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.
 
> 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.
 
-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]