What kind of logic do you need? From the examples (screenshots) you
gave, I think simple prepositional logic would be enough. In that
case, I think the language could be a subset of Python, so you don't
need to come up with your own. All you would need are regular Python
logic operators and a mapping between the predicates you make
available on the web interface and boolean python functions. I'm
assuming predicates would be treated atomically and handled by your
code (check if name/arguments are right, so as not to allow arbitrary
functions to be called, and sanitization can be done inside the
function). Then you would need a propositional logic parser to make
sure the input is a valid (python boolean) expression, and eval it
from the database as needed. Would handle the use cases you have in

On Tue, Aug 11, 2009 at 6:01 PM, Eduardo
Felipe<eduardofelip...@gmail.com> wrote:
> Hi there!
> I'm Eduardo and I'm working on Reviewboard for Google Summer of Code.
> My proposal included policy support, and as I was discussing it with
> Christian on IRC when he asked me to open up the discussion to the
> entire community.
> So, to quote (parts of) my proposal:
> <quote>
> During the deployment of ReviewBoard in my last employer we've had to
> establish that no code is good until it was reviewed by at least three
> programmers, two being senior. Since currently there is no way to
> specify this in ReviewBoard reviews sometimes ended Close as submitted
> without the minimum reviews rule. Talking to everyone about it solved
> the problem, but in a large organization there should be a way to
> prevent users from breaking the rules.
> As such I propose, based on the suggestion on the Wiki, to create an
> admin module to allow arbitrary policies for common actions. In this
> way a rule could be created for anything, from reviewing, to updating
> a diff, to marking it "Ship it!" or allowing it to be closed, deleted
> or submitted, viewing a review request, reviewing it, joining a group,
> etc. covering all the aspects needed for policy support.
> A suggested implementation would be based on filters, AKA predicates,
> used to allow or disallow an specific action.
> The priority should be what users want the most, and the interface can
> be done in the regular way or providing a Domain Specific Language, a
> very reduced subset of python, much similar to Django's template
> engine.
> Optionally the access to repository could be based on user's
> permission, instead of a global repository permission, by using the
> user's own credential to the repository, adding an extra level of
> protection.
> </quote>
> Now, to get to the good stuff:
> I think it is necessary to have a way of defining arbitrary rules
> based on the attributes of objects involved in an action.
> For instance, the objects involved in the action of "Close as
> submitted" is the user who is performing the action and the review he
> is performing it to.
> Now one could want to, for instance, create a rule such as "Review
> requests can only be closed as submitted if they have at least two
> ship-its". In order to express that in a neat way, I'm thinking about
> implementing what is called a "Predicate Editor" or "Expression
> Builder". I've attached a couple of examples so you can get a grip of
> what I'm thinking of doing.
> This predicate editor can test any aspect of pretty much any attribute
> of the objects involved in the action. So you can check things like
> "User belongs to group Foo" or even the negation as "User does not
> belong to group Foo", strings attributes such as "Review title
> contains BAR", date attributes "Review updated in the last 3 days",
> etc.
> By now you can imagine this is a complex feature. Indeed is so complex
> that having a Domain Specific Language for dealing with those
> predicates is NOT an overkill. The idea behind having a DSL is that we
> can store the predicates as text in the database, allowing them to be
> shared and migrate, but this DSL is not Python code, nor it should be,
> and as such it needs to be compiled down to python, evaluated and
> stored into memory, so they can be used to test actions later on.
> There is a limit of how far a regex based parser can go. If the DSL
> turns out to be a Context free language, regex simply won't be able to
> parse it. Now we can have two approaches for this problem:
> 1 - Create the DSL as an XML-type language, and use a XML parser + a
> custom DOM walker to generate the python code.
> 2 - Create a DSL thats more human friendly than XML, and use a
> compiler generator tool, like ANTRL, to generate a compiler that will
> in turn yield the python code.
> The advantage of approach 1 is that it won't need any external
> library, as python already have XML parsing libs included. The
> disadvantage of this approach is that I think it will be harder to
> build a parser for the web interface that also manipulates it. I could
> be wrong, but I've been burned before by XML in a browser, and I
> started using JSON, which is more "javascript friendly".
> Using the second approach is easier to build a small, readable,
> parseable language, but in order to compile it down to python we would
> need to include an external resource, such as a runtime lib for ANTRL,
> and that could have a great onus for the developers (the install of
> ANTLR is kinda of a PITA).
> This is a hard decision, so I would very much appreciate you input on
> it. If there is a policy wanted that a predicate engine would not be
> able to check, please let me know so we can figure something else out.
> Thanks a lot.
> Eduardo.
> >

You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to