thanks amitaibu for pointing to this thread..

I've just digged through the ca code. So I try to compare both modules:

First of let's compare the basic concepts:
* Your predicate is what in rules is a rule. In rules there is also the possibility to have default rules - like you have with your predicates. Btw. in theoretical computer science the term "predicate" is used for something else: http://en.wikipedia.org/wiki/Predicate_(logic) - which confused me at the beginning as I thought it might be a special kind of condition.
* Your "triggers" are what in rules are events. In rules, rules get triggered when events occur..
* Rules additionally provides rule-sets, a set of rule which is defined to work with some defined arguments. It's somehow like a subroutine and can be executed by action or code.
* It's also possible to provide default rule sets, which is useful for a module to come with some default behaviour which users can adapt. Events do not really fit here, as an event is just the possibility to react on. But the concept of an event, doesn't necessarily need a reaction or so.
* Rules works on top of variables, which always are of a special data type. Events provide variables, but actions might add new variables too. In workflow-ng this was similar, but variables were just called arguments everywhere. As far as I've seen you still work argument-based, but have removed features like allowing actions adding new variables from ca? Allowing actions to add new variables is really useful when you want to get related data from existing data, e.g. return the referenced user of a node, or the content profile of a user.

ok, let's come to the features...
* As mentioned, rules allows actions to add new variables, which then consequent actions and rules may use.
* Rules features the concept of input evaluators, which allows module to provide input evaluators to rules. Then those input evaluators can be used in every text input field of conditions and actions - so there is an input evalutor for PHP code in rules as well as an token input evalutor shipping with token. So rules work fine without token, but as soon as the token module is installed you can make use of token replacements everywhere...
* Rules comes with a generic scheduling mechanism, which allows you to schedule the execution of every rule set. So you can schedule the execution of every rule, condition or action... E.g. you could use that in ubercart to automatically decrease the price each day or so - all configurable by the user.
* Then of course there is a lot of useful integration for rules... E.g. there is CCK integration which allows you to compare fields or populate a fields value. Furthermore rules supports executing drupal core actions.
* Rules is written with performance in mind - so it's optimized for fast rule evaluation and intelligently deals with rules.inc files inclusion for the other modules.
* Rules has improved logging compatibilites working fine even with recursive evaluation of rules - which is important for people to debug rule evaluation.

ok, then let's talk about the code.
* Rules is basically workflow-ng, but I've rewritten and refactored a lot of it - so it's easier to extend and adapt it.
* Rules tries to separate different functionality in different parts, e.g. code for dealing with variables or data types sits in it's own include file and provides useful API functions. This makes the code easy to read, maintain and extend.
* Rules has an much improved data API, which allows to specify custom data types. Additionally to "old entities" of workflow-ng, rules covers simple variables like strings, numbers or dates and allows users to input them on configuration time. So one can add further data types that use their own input form on configuration instead of the usual mapping to a variable.

Of course, rules is more complex than ca as it has a lot more features. But I do care about high quality code and good factorisation, so the code is easy to read and maintain - as this is really important for me to.. E.g. the variable subsystem deals with loading/saving variables for actions - just relying on the data type's implementation to deal right with the data.. I've also done some simpletests ensuring rules evaluation works right. Then do not forget, I'm available for digging through the rules code if there would be any troubles...

It's really easy to write things for rules. Check the docs: http://drupal.org/node/298534
In comparison to workflow-ng I've worked on simplifying it - which let me create the input evaluation system. So you don't have to really care about integrating with token or so, it just works!

ok, let's consider how ubercart could integrate with rules:

* As discussed at the drupalcon, you could support invoking rule sets and add ing rule-sets returing a boolean as condition. So one could set up any rule set and fire it up by the integration. But as zmove already mentioned, it would be quite complicated to handle as you have 2 similar systems: ca and rules.

Integrating both systems seamslessy these way might get hard - as I've seen you also changed the "entity system". So you'd also need a mapping of data types.. Perhaps it would make more sense to use the same condition and action format, as well as the same data types. But anyway for both solutions, you would be able to use only a subset of available stuff or replicate the whole module...

So if you would completely rely on rules, you could do it this way:
* I think some of your "triggers" would be best implemented as a rule set. Just provide a default rule set and execute it out of your code.
a) You could lock the rule set and build your own UI for configuring it.
b) You could lock just on rule of the rule set, build your own UI for configuring this rule, but allow users to add further rules to the rule set through the rules interface
c) You could not lock the rule set and point at the rules admin page for editing the rule set for modifying it.
d) You could embed the rules UI into yours, which seamlessy makes use of the rules UI for editing rules. So once you edit a condition or action, you would make use of the rules UI and once submitted you get back. Furthermore we could modify the breadcrumbs during editing you they point back at the ubercart UI. So there are some possibilities for integrating the UI, I'd help here if I can. Of course I'm also open for rules UI improvements..

If having a dependency is a problem for you, you could also do it that way:
* Rely on rules as above, but don't force the people to install rules.
* If rules is not available, provide a simple alternative that takes the available rules conditions and actions provided by ubercart and allows a simplified configuration of those. Probably best you maintain a whitelist of your conditions/actions working with your simple alternative (e.g. by an extra hook).
* If one wants more, e.g. use tokens or using other conditions/actions one has to install rules.

So the simple alternative could fullfill basic needs, while people needing more can install rules.