Aw: Re: Fwd: Update-Accelerator 3.0

[Bernhard Bitsch <Bernhard.Bitsch@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]



> Gesendet: Mittwoch, 06. März 2013 um 23:08 Uhr
> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
> Cc: "development(a)lists.ipfire.org" <development(a)lists.ipfire.org>
> Betreff: Re: Aw: Fwd: Update-Accelerator 3.0
>
> 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.
>
>
No problem. But this solution must give us th possibility to manage the file store from the WUI.
I don't want to miss this feature.

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

The loops are not avoidable by a JIT compiler ( Perl does this too ).
The storage application must loop over the various categories.
At a short look on PCRE I could not find a possibility for efficiently assembling several single RE's/URI's to one.
This is necessary if we want the user to extend the rule set. A main problem in the actual implementation is the extension by adding a new alternative.

- Bernhard