lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev anchor->FileCache (was: patch 8 - reusing temp files)


From: Leonid Pauzner
Subject: Re: lynx-dev anchor->FileCache (was: patch 8 - reusing temp files)
Date: Tue, 6 Jul 1999 14:11:21 +0400 (MSD)

>      * From: Klaus Weide <address@hidden>
>      * Date: Tue, 6 Jul 1999 02:20:29 -0500 (CDT)


> There is the different case of compressed (remote) HTML and text/plain
> documents that lynx displays internally, for those temporary copies
> are alos kept around although there doesn't seem to be a good reason
> for it (unless lynx were changed to re-use those files upon re-loading).
> But you don't seem to be talking about that case.

> Reuse of the content of those temp files (for both cases) would mean
> there is no check against stale versions, unless either some real cache
> freshness checking logic is implemented or the files are removed more
> aggressively.

> (anchor->FileCache is completely separate, as far as I have seen, from the
> SOURCE_CACHE:FILE temporary cache file.  The two mechanisms don't know

Yes, these two mechanisms don't know about each other,
mostly because of different creating/expiration/removing conditions.
Also, binary files (e.g. images) will not start HTML_new() so CacheThru_...
will not create SOURCE_CACHE copies while anchor->FileCache do.

>From the other hand, we may want to make SOURCE_CACHE not so expensive
as we have now: say, if there is a proxy and (some heuristics) we know the
document is not cached there or downloading time is noticeble (remote
proxy), then make a SOURCE_CACHE copy... Such conditions should be
configurable by user.


> about each other.  It also seems that SOURCE_CACHE doesn't apply to
> compressed HTML files from http servers (but I haven't tested that;
> I just expect the p->name that is tested in CacheThru_new would say
> "file" in that case instead of "http")).

There is CTRACE message there, you can check a trace log (haven't tested
the result either).

>   Klaus




reply via email to

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