Re: [RFC] or ACLs

On 9/26/2012 5:07 PM, Alex Rousskov wrote:
> I am glad AND/OR ACLs will be allowed.
>
> It is unfortunate that our views on what the ideal Squid configuration
> language should provide (and how to get to that ideal) differ so much. I
> focus on maximizing flexibility and expressiveness of the language while
> you focus on minimizing misuse and abuse. I cannot think of any
> real-world example where humanity succeeded optimizing in_both_
> directions. While both expressiveness and safety are good principles and
> usually co-exist, one principle has to dominate for the design to flourish.
>
> Now that the solution to an immediate practical problem has been agreed
> on, I do not think it makes sense to continue this discussion between
> the two of us. Hopefully, others will chime in and help form a
> consensus, but I am not optimistic.
>
>
> Thank you,
>
> Alex.
I was thinking and what AND/OR different from the ACLs as it now?
today it's a strict "AND" for the whole line so in a sense of calculator
it's:
http_access allow AND acl1 acl2 acl4 (+1,2,3,4)
which is the better choice if you do ask me for acl validation instead
of using:
http_access allow AND acl1 AND acl2 AND acl4 (1+2+3+4)
(I dont remember the literal way of the different ways to this
calculation thing)

If you do ask me one of the best things I do like about squid
configuration is not having a "programming language" like structure.

Ff you will take for example varnish configuration.
you will need to learn how it all fits together to even write the basic
configurations while with squid you can simply write:
one acl for src allow
one cache_peer directive + allow\deny acl
one http_acces \ https_access
and refresh_pattern if needed at all

So I think that adding the feature OR like this:
http_access allow acl1 acl2 acl4 OR acl5 acl6
http_access allow OR acl7 acl8
when the OR is only on acls after the OR will be accounted as OR can be
understandable and will not effect any current configurations.

Flexibility is a good thing but IN steps.
What I mean is that the current configuration syntax is based on static
statements which can be understood in seconds for almost anyone who just
read it.

The way system administrators looks at the product can be seen from
couple angles like:
while they need the product.
while they need the product to do something specific.
while they have a product the was used before.
and maybe some other points of view of course.

While they prefer the software to have "all they need" to do a specific
task they would admit that in other points encountering the product they
prefer simplicity.

I would ask just to now if i'm wrong or not:
all this big list of
http_access deny w1 r2
http_access deny w2 r2
http_access deny w3 r2
http_access deny w4 r2
http_access deny w5 r2

can be replaced with one external_acl helper?
(since I do not know what w1 and r1 acls are).

Eliezer

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il