lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev dev.16 patch 3 - SOURCE_CACHE etc.


From: Leonid Pauzner
Subject: Re: lynx-dev dev.16 patch 3 - SOURCE_CACHE etc.
Date: Fri, 10 Dec 1999 13:32:50 +0300 (MSK)

9-Dec-99 21:02 Klaus Weide wrote:
> On Thu, 9 Dec 1999, Leonid Pauzner wrote:
>>
>> Speaking of SOURCE_CACHE, I think it would be nice to allow different
>> number of documents for source cache against HText cache. HText keeps
[hmm, you are right: having the cached source without HText will require
expiration logic...]

> I have said in the past that I think the whole source cache thing uses
> a fundamentally wrong approach.  I still think so.  Since it more or
> less works for what it does, and I haven't provided anything better,
> there wasn't much point in belaboring it.

> Retrieving from "source cache" should go through getfile() like other
> requests, instead of doing its own thing and duplicating stuff that is
> done in the normal path.  (I think the history of changes shows that
> those shortcuts taken have resulted in lots of problems - things that
> happen in the normal path and had to be discovered and duplicated for
> "reparsing".)

There is one fundamental difference between cache for "reparsing" and
cache in HTTP sence we discussed before. Reparsing -just another
presentation of html document- should be done on the same source, no
cache-control or expire logic here at all. That is why it was
implemented in mainloop and not in getfile [which will require something
like "disable expiration logic" in many places]. Instead, in
the first case more mainloop changes welcome to make things more
obvious, like curdoc.line!=Newline before HText_pageDisplay(): I mean
current newline logic vs proper refresh_screen check where complete
refresh is really assumed.

[...]
> A cahce without any cache-control features - one that caches everything
> that comes in and never expires etc. - just doesn't make sense, it's
> a bloating monster.

> What about the good old advice - if you want a real cache, use an
> external one.

And my original point was in d'ownloading a document from the history
page: apparently some documents are never cached (or always expired
which is the same) so external cache will not help here (and I have
one). That was you who say that documents from the history stack should
be assumed without update, aren't you? And we could (though indirectly)
get downloaded document uncached when clicking 'x' no-cache on its link
and than download if we got a prompt or got from the history page if it
was text/html or text/plain.


>    Klaus





reply via email to

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