great, not sure if I will do this for 4.0 though, will see, but certainly this sounds like it can work nicely.

Keeping it decoupled as it was is/was probably the best thing, definitely the right way to go.

So it ruleflow still "experimental" class for 4.0? or is it now officially part of the core?

Michael

On 5/22/07, Kris Verlaenen < kris.verlaenen@gmail.com> wrote:
The reason it was specified in a separate class is that it is still
more experimental, and I didn't want to interfere with the core stuff
too much.  I don't see any real downsides, ruleflows are indeed just
another asset I think.

Kris

On 5/22/07, Michael Neale < michael.neale@gmail.com> wrote:
> Kris, looking at the ruleflow stuff (not the core, but the .rf stuff), I
> have a suggestion on how to make it more integrated with the ruleset/package
> structure.
>
> At the moment Ruleflow packages are a seperate entity that is merged into a
> RuleBase as needed.
>
> Does anyone have any objections if we add the ability to have ruleflow as
> part of a rule Package itself? (thus when that package is added to the
> rulebase, all the processes for ruleflow go along with it)? so a ruleflow.rf
> file for example becomes just another asset like a drl?
>
> Kris? thoughts? downsides?
> No need to change the current API.
>
> Michael