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

[Leonid Pauzner]

10-Dec-99 07:41 Klaus Weide wrote:
> On Fri, 10 Dec 1999, Leonid Pauzner wrote:

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

You forget lots of places in mainloop, such as check a replay from POST,
which only required when network transmition will be the case.

>> 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.
I was saying... but never get implemented mostly. sory.
At least your from_source_cache_p will not made things more clear,
that should be LYMainLoop.c PRIVATE until it will be completely removed
one day (it was a fix for curdoc.line and www_search_result glitches
anyway).

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

I mean two HText_pageDisplay() calls in mainloop(). It looks very
strange for me to use  if (curdoc.line != Newline)
as alternative for  if (refresh_screen). It is not clear,
we set refresh_screen on a lots of places in LYMainLoop.c
and does not use it explicitely.
Also I think Newline should be set to www_search_result in
handle_LYK_WHEREIS() and in that "force_load" part to pick
HTFindPoundSelector() result. Perhaps I will submit a patch.


        /*
         *  If the curdoc.line is different than Newline then there must
         *  have been a change since last update.  Run HText_pageDisplay()
         *  create a fresh screen of text out.
         *  All display_partial calls ends here for final redraw.
         */
        if (curdoc.line != Newline) {
#ifndef NO_NONSTICKY_INPUTS
            textinput_drawn = FALSE;
#endif

            refresh_screen = FALSE;

            HText_pageDisplay(Newline);
---------------------

and next after above nearly the same chunk of code starting with:

        /*
         *  Refresh the screen if necessary.
         */
        if (refresh_screen) {
#if defined(FANCY_CURSES) || defined (USE_SLANG)
            if (enable_scrollback) {
                clear();
            } else {
                erase();
            }
#else
            clear();
#endif /* FANCY_CURSES || USE_SLANG */
            HText_pageDisplay(Newline);


>> [...]
>> 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.
We do not need "always caches anyway", at least responce from
POST request for sure. We want it in very special situations only.

> 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).
Well, this is extra.
> (We could display the cache filename on the INFO screen for folks who
> really want to do this.)
No. They could study the trace log if they are so interested...

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

Yes. We starting to understand each other at this moment:)
While 'd'ownloading from the History page is a special case,
recommended in Users Guide, it would be nice to utilize source_cache
copy when we already have it.

BTW, we usually have *only* text/html documents in the History page,
exceptions are rare (local/ftp directories and text/plain documents).
No binaries.