I agree to the privacy violation problem for man-in-the-middle caching... That's why I am not allowed to use it, that is the initial problem. There must be a way to store in cache things like files which are hosted at some filehoster on the internet. But okay, at the moment this is just not possible (legal way).
When we jump right ahead to discuss technical details, I would like someone to check out if we can easily control the cache to store our files, so that we don't have to manage our own one.
You could give squid a separated cache-dir for update-things. Did you check the new "rock-storage" type of squid? It is really fast. Also the newer versions of squid are multithreaded or at least multiple instanced.
So I recommend using squid's cache. It is well established over many years and very fast. There just has to be a mapping for the files to query them from cache storage. Squid has an internal mapping, if it would be possible to get into that API - the problem will be small.
2013/3/6 Michael Tremer michael.tremer@ipfire.org
On Wed, 2013-03-06 at 22:23 +0100, Bernhard Bitsch wrote:
I don't think we should make a new solution based on squid's caching, too.
The existing Update Accelerator is written as a rewriter module to squid.
This model is strong enough to realize the function " caching of frequent file requests ".
When we jump right ahead to discuss technical details, I would like someone to check out if we can easily control the cache to store our files, so that we don't have to manage our own one.
My first idea for a redesign of the accelerator was generalize the conditions for caching.
In the moment all conditions can be described by the pattern
if URI match set of (sample URI's and RE'S)_1 & URI !match set of (sample URIs and RE's)_2 then
check(URI)fi
This can be enhanced if the sets of URI's and RE's are condensed to two regular expressions for each caching class, actually called "vendor".
Then the check for caching is just a loop over all classes.
A second enhancement can be achieved if the most requested checks are made first. The loop terminates by the first match.
The latest version of PCRE comes with a fast JIT compiler for regular expressions. We should take advantage of that instead of running thrugh loops.
I agree that all URLs should be configurable.
-Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development