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 mind?
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 reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
