[Top][All Lists]

[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: Klaus Weide
Subject: Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_INCOMPLETE
Date: Fri, 7 Apr 2000 14:01:43 -0500 (CDT)

On Fri, 7 Apr 2000, Philip Webb wrote:
> 000407 Klaus Weide wrote:
> > An incomplete document shouldn't appear as a valid source cache entry, IMO.
> i disagree: source cache should reflect exactly the rendered document.

That's your opinion, so far.

> 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's questionable.

> i also don't like undocumented geheime IMO-Diktaten.

You saw the changes described in detail in the announcement to this list.
You can read them in CHANGES (for 2.8.3dev.17) to refresh your memory.

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

Ok, that's another possibility.

> > It's actually 3) that is implemented: that was the intention.
> no, do (1a) instead.

Your opinion.

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



reply via email to

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