Re: [RFC] or ACLs

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
Received on Wed Sep 26 2012 - 22:46:45 MDT