101 lines
3.2 KiB
ReStructuredText
101 lines
3.2 KiB
ReStructuredText
Rules
|
|
========
|
|
|
|
|
|
|
|
Basic definition
|
|
****************
|
|
To define a new rule
|
|
|
|
|
|
::
|
|
|
|
> when <predicate> then <action>
|
|
|
|
Rules can have name, so you can also use the syntax
|
|
|
|
::
|
|
|
|
> def rule <name> as when <predicate> then <action>
|
|
|
|
|
|
Existing rule engines
|
|
*********************
|
|
|
|
I am not quite sure yet about the implementation. I have started to search on the net to see if
|
|
I can found some interesting implementation that I can use.
|
|
|
|
I found:
|
|
|
|
* Durable Rules Engine : https://github.com/jruizgit/rules
|
|
|
|
Python implementation, with the rule engine written in C (or C++) to be faster. A good candidate
|
|
|
|
* PyKE : http://pyke.sourceforge.net/knowledge_bases/rule_bases.html
|
|
|
|
Another Python implementation of the rule engine
|
|
|
|
* Business-rules : https://github.com/venmo/business-rules
|
|
|
|
* Intellect : https://github.com/nemonik/Intellect
|
|
|
|
* CLIPS : http://www.clipsrules.net/
|
|
|
|
A standard. Run on a separate server. I need to check how it can be embedded, or dockerized
|
|
|
|
* And of course drools : https://www.drools.org/
|
|
|
|
Another standard
|
|
|
|
I am not an expert in rule engine. So I guess that the best way to figure out what engine to use it to list what are the feature that I need.
|
|
|
|
|
|
Use cases
|
|
*********
|
|
|
|
I see the rules engine like the caching service or the logging service. It can be used anywhere in the code.
|
|
It's not just a global feature of Sheerka. It's another way of achieving common task.
|
|
|
|
For example, in the print service, I want to print all the failed ``ReturnValueConcept`` in red.
|
|
Doing it in an imperative way (ie coding this functionality) is
|
|
|
|
1. Intrusive in the code. I need to understand what code and where to put it
|
|
2. Not straightforward : if I want to that all successful ``ReturnValueConcept`` in green, chances are that I will have to rewrite some code
|
|
|
|
So It has to be declarative. With an engine that takes these declarations and correctly paint the outputs.
|
|
And a declarative system that accepts conditions is (I guess) a rule engine.
|
|
|
|
So let's try something like:
|
|
|
|
::
|
|
|
|
> when action==Print and obj==ReturnValueConcept and obj.status then print_the_status_in_red()
|
|
|
|
We immediately see that the rule engine will have to be aware of the current system.
|
|
So the chosen rule engine will have to manage state or facts. I haven't checked all the listed one, but I am quite sure that they all do,
|
|
as it's the minimum requirement for a rule engine.
|
|
|
|
I also need two types of rules.
|
|
|
|
* permanent rules
|
|
It will be triggered as long as the system allows it
|
|
|
|
* one use rule:
|
|
it will be triggered only once
|
|
|
|
If I take my example to color the status of the ``ReturnValueConcept``, it may be a permanent rule,
|
|
that will apply to any output, or it can be something that is specific to the current execution context.
|
|
|
|
|
|
In the predicate part, I need to control how expression are evaluated.
|
|
For example in the expression ``action==Print``, Print can be a string ('Print'), a builtin concept (``BuiltinConcepts.PRINT``) or even another concept
|
|
|
|
|
|
In the predicate part, as well as in the action part, I must be able to used other concepts
|
|
|
|
::
|
|
|
|
> def concept status is not ok as <whatever suits>
|
|
> def concept paint in red as <whatever suits>
|
|
> when status is not ok then paint in red
|