lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes)


From: Klaus Weide
Subject: lynx-dev automatic uncaching (was: PATCH [dev22]: source caching fixes)
Date: Thu, 15 Apr 1999 03:58:14 -0500 (CDT)

On Wed, 14 Apr 1999, Vlad Harchev wrote:
> On Thu, 15 Apr 1999, Leonid Pauzner wrote:
> 
> > 14-Apr-99 13:32 Vlad Harchev wrote:
> > >    I found another bug: if there is something on the cache stack (say doc 
> > > A
> > > -current doc and doc B), and we go to 'O' and change something, only
> > > appearance of 'A' is changed, the appearance of B is not changed - the 
> > > cahced
> > > version is used. IMO it will be better to uncache everything in the stack.
> > > This is best tested with 'links are/not numbered' - since rendered 
> > > versions
> > > differ a lot.
> > 
> > That was a very expensive solution before SOURCE_CACHE
> > but now this can be done nicely by adding more parameters to the function
> > above and avoid using of HTuncache_current_document() calls.
> > Until we keep a compatibility with SOURCE_CACHE:NONE this is a little messy.
> 
>   But the way it's implemented now should be considered incorrect. IMO, user
> should understand that changing options have a penalty and not to do this
> very often. Also, IMO the use of caching proxies with SOURCE_CACHE:NONE won't 
> make things messy/slow. IMO, we should implement the correct behaviour.

I don't consider the current behavior as incorrect or a bug.  It's just
one of several possible behaviors.  It's nice if you want to implement
an alternative, but don't force it on everyone (including people with
slow net connections), make it configurable.

Re "user should understand that changing options have a penalty":
maybe, but don't just go and increase the penalty for everyone more
than necessary, without a chance of opting out.

    Klaus


reply via email to

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