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

[Klaus Weide]

On Fri, 10 Dec 1999, Leonid Pauzner wrote:

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

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

Not in many places.  Just one flag should be needed to say "take this
from the souce cache if it is there, overriding all other concerns",
and changes to avoid HTuncache_current_document calls from mainloop
(or call a modified version HTuncache_but_dont_completely_forget).

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

I don't understand.  Are you saying that the changes to mainloop() to
support source_cache have made anything clearer?  Definitely not for
me.

You give too little detail for letting me understand what you mean wrt.
"proper refresh_screen check".

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

You should be able to tweak that external cache so that it ignores
pre-expiration and even no-cache and always caches anyway.  Although
I haven't tried it in a while, I believe there are configuration options
for this in squid.

Also, if the file is cached with SOURCE_CACHE:FILE - it's already in
a file on your disk, you can access that file directly and do with it
what you want...  (You first have to figure out the filename though).
(We could display the cache filename on the INFO screen for folks who
really want to do this.)

> That was you who say that documents from the history stack should
> be assumed without update, aren't you?

If with "should be assumed without update" you mean "should not cause
a new network request if they are in the cache", and with "from the
history stack" you mean "accessed from the History Page or by PREV_DOC",
then yes.

But that referred to getting a rendered version and the traditional
"rendered docs" cache.  'D'ownload isn't about getting a new rendered
version, so it couldn't use the "rendered docs" cache of course.

If you are suggesting that 'd' *in the History Page* should act differently
and take a source_cache copy if available - but not 'd' on another link -
yeah I see some logic in that.  But that would of course only help for
text/html.

> 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
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sorry, I don't understand what you are tying to say.

> was text/html or text/plain.


   Klaus