[PATCH] AND and OR ACLs v15

On 05/01/2013 09:57 PM, Alex Rousskov wrote:
> On 05/01/2013 07:28 PM, Amos Jeffries wrote:
>>>> On 21/12/2012 6:28 a.m., Tsantilas Christos wrote:
>>>>> - The new acls converted to Checklists in order to computed.

>> The issue I had with the earlier version was that each ACL test involved
>> allocating a whole new ACLFilledChecklist object and initializing it.
>>
>> What I had been evisioning when we discussed this earlier was a sleek
>> little design where the ACL AND/OR type was a pre-constructed tree with
>> the node match() function doing the logic of whether to walk down
>> sub-ACL A or sub-ACL B to produce its own result. The whole thing using
>> 1 ACLFilledChecklist across the entire process in the same way that 1
>> ACLFilledChecklist is used today for the whole set of *_access lines no
>> matter how long or complex they are.

> Great, this matches what I am working on.

The attached patch updates ACL handling to support the following:

* Expressiveness: Two new boolean ACLs (all-of and any-of) that allow
admins to group ACLs as needed, to express complex conditions more
naturally, with fewer squid.conf lines. Conditions such as "(a or b) and
(c or d)" are easily expressed now. Explicit groups of ACLs of different
types can now be configured, named, and used in any ACL expression.

* Correctness and performance: When a slow ACL (that has suspended
checks to wait for an async lookup) is ready to resume checking, Squid
resumes checking from that ACL, instead of rechecking all ACLs for the
same action (or the same squid.conf directive) again.

* Internals: Store ACL-related configurations as an expression tree,
streamlining the code and clearing the way for future math-style/natural
ACL conditions support. The usual boolean operators (and, or, and not)
form intermediate nodes while good old configurable ACLs become tree
leaves. The new all-of and any-of ACLs use the boolean operators (and
also become intermediate nodes, of course).

I have also attached an annotated and sanitized debugging log showing
how the new ACL tree traversal looks in cache.log.

In retrospect, I do not think it was possible to add AND/OR ACLs
correctly without most of the changes in this patch. I am sure there
will be more major ACL-related improvements in the foreseeable future,
and this patch is another step to make those improvements possible.
FWIW, I do not think I would be able to implement this without the
previous cleanup step (r12176).

I hope these changes address all concerns expressed so far.

HTH,

Alex.
P.S. While I started with pieces of his earlier patch, Christos is not
responsible for the bugs in the attached patch.