title: Rules Engine: Best fit for an embedded system
body: <p>I have been doing some research on the rules engines that would be more appropriate run on a embedded system. The system will collect information from sensors and according to that information, make specific C/C++ calls. An example would be: </p>
  
  <pre><code>IF RainSensor.value &gt; RainSensor.threshold 
  THEN call( GarageWindow::close())
  </code></pre>
  
  <p>Being GarageWindow a C++ class, living in the binary that links to the Rules Engine library.</p>
  
  <p>I cannot make assumptions on the capabilities of said embedded system. The requirements for it are:</p>
  
  <ul>
  <li>Minimum footprint.</li>
  <li>Portable</li>
  <li>Able to make function calls (make C/C++ calls from its RHS).</li>
  <li>Should accept new rules at runtime.</li>
  </ul>
  
  <p>I would need to give alternatives according to its capabilities (to be defined in the future), the assumptions are:</p>
  
  <p>1) The embedded system supports nothing(no JVM, no python, etc): </p>
  
  <p><strong>CLIPS</strong> as C library or clipsmm as C++ library. Both usable in commercial applications (GPL for clipsmm). </p>
  
  <p><em>Advantages</em>: Open Source. Very well tested/documented. Portable and can run on low memory footprint. It’s possible to call C or C++ functions from its RHS section. Most likely the Rules Engine will need to interact with a C or C++ software.</p>
  
  <p><em>Disadvantages:</em> It is not thread safe. It supports only forward chaining.</p>
  
  <p>2) The system supports python: </p>
  
  <p><strong>PyClips:</strong> </p>
  
  <p>Python interface to CLIPS. Functionality remains the same as in the previous case. Using this would only benefit if python calls need to be made in the RHS section. Any advantage/disadvantage I miss?</p>
  
  <p>3) System supports JVM:</p>
  
  <p><strong>Jess</strong>:</p>
  
  <p><em>Advantages</em>: Nice integration with Java objects. CLIPS-like scripting language. Forward and backward chaining. Automatic listening to Java objects to modify slots.</p>
  
  <p><em>Disadvantages</em>: Licensed. Can only define new classes at compile time.</p>
  
  <p><strong>Drools</strong>: </p>
  
  <p><em>Advantages</em>: Open source. Documented. Java integration. Forward and backward chaining.</p>
  
  <p><em>Disadvantages</em>: It is more designed to work on the web (that's my impression).</p>
  
  <p>What would be the advantage of Drools vs Jess in an embedded environment?</p>
  
  <p>Both can only add new classes at compile time. CLIPS can at runtime. On the other hand,if the C++ code that updates clips instances is old, any new class created directly in CLIPS will not be matched to any other class in the calling C++ code. Therefore, the disadvantage of recompiling of the Java options is not such.</p>
  
  <p>Is there any other appropriate engine for embedded systems that I am totally missing?</p>