I do agree with your point 1,2,3, rule-based is better in some cases, but it's not as expressive, sometimes you have to express the logic in a non-straightforward way to satisfy your need, when the logic get complicated. We're trying to make the system flexible from the backend, and improve the usability at the UX level. For example, the constants inside the language will go to a separate section in the UI and will have various components of tuning them.
If the DSL code is organized well, it's going to look as clean as the rule based one.
Comments
The systems that I've seen of this nature have been rules-based, like this:
if A allow, else continue to next rule
if B deny, else continue to next rule
if C allow, else continue to next rule
deny all
For example, ufw rules have that form.
I see a few advantages compared to Boolean operators:
1. Easier to diff and version control.
2. Easier to build UI for, for example, to show which rule fails for a particular user.
3. Simpler to implement, no recursion in the DSL.
4. Arguably simpler to use.
5. Immediately obvious how short-circuiting works.
Why did you choose to go with Boolean operators rather than rules?
I think this is all about trade off.
I do agree with your point 1,2,3, rule-based is better in some cases, but it's not as expressive, sometimes you have to express the logic in a non-straightforward way to satisfy your need, when the logic get complicated. We're trying to make the system flexible from the backend, and improve the usability at the UX level. For example, the constants inside the language will go to a separate section in the UI and will have various components of tuning them.
If the DSL code is organized well, it's going to look as clean as the rule based one.