On 27.09.2012 03:18, Kinkie wrote:
Here's my cue :-)
I tend to favor expressiveness, and I'd love to see the access rules
evolve
to a tree-like structure, with sub expressions and explicit Boolean
operators.
But I also think that the one-of / all-of proposal is clear and is
more
expressive than what we have now, so I support it.
On Wednesday, September 26, 2012, Alex Rousskov wrote:
On 09/25/2012 09:02 PM, Amos Jeffries wrote:
>> So, if we change the name to "any/one-of/first-of/etc" or use the
"is/="
>> syntax above, will you be OK with adding OR ACLs?
> Does 'is' mean OR or AND or IF or equals ?
"is" means what it means in English: equality or definition.
> Does '=' means OR or AND or assignment ?
"=" means what it means in programming: equality or assignment.
The expression on the right hand side determines what is being
assigned.
Since neither of us liked "or acl1 acl2" style, I proposed "is acl1
or
acl2" style because it is natural and will allow us to support more
complex expressions later. I now understand that you do not like
that
direction, so I will use "one-of" you suggested unless others help
form
a different consensus.
> Please consider names that provide you with easily distinguishable
set
> of types that still match the underlying semantics.
"one-of"/"all-of" at
> least hint at the OR/AND set semantics.
I will use your "one-of"/"all-of" names.
> To summarise: Yes I'm okay with adding OR type. Provided the
larger
> picture is considered when adding them.
>
> You may as well add the AND type as well, since they only differ
in
> match() strategy. Then you have grounds for adding a
Conditional.h/cc to
> src/acl which defines these and any future boolean node types.
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.
On the contrary. The "safe" route I would I would very much like to see
is one day to have the very flexible and expressive syntax:
acl label = (condition)
Where condition contains at least 'or', 'and', '(', ')', '!' operators
to construct a true boolean tree structure for the ACL test. That syntax
has much wider understanding than our existing definition structure and
will cause far less confusion overall.
If you want this project to jump straight to that for 3.4 I have no
problem with the naming. It is only for this half-stage where its almost
there but missing vital bracket/scoping operators that I am concerned
about understanding and migration problems.
IMHO its not that much work to add a Conditional data type which hold
ACL node pointers instead of data values to test against. With a
strategy for each operator type. The parser would need to be
semi-recursive like any boolean parser - but that is not a big problem.
HTH
Amos
