great, not sure if I will do this for 4.0 though, will see, but certainly this sounds like it can work nicely. <br><br>Keeping it decoupled as it was is/was probably the best thing, definitely the right way to go. <br><br>
So it ruleflow still "experimental" class for 4.0? or is it now officially part of the core? <br><br>Michael<br><br><div><span class="gmail_quote">On 5/22/07, <b class="gmail_sendername">Kris Verlaenen</b> <<a href="mailto:kris.verlaenen@gmail.com">
kris.verlaenen@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The reason it was specified in a separate class is that it is still
<br>more experimental, and I didn't want to interfere with the core stuff<br>too much. I don't see any real downsides, ruleflows are indeed just<br>another asset I think.<br><br>Kris<br><br>On 5/22/07, Michael Neale <
<a href="mailto:michael.neale@gmail.com">michael.neale@gmail.com</a>> wrote:<br>> Kris, looking at the ruleflow stuff (not the core, but the .rf stuff), I<br>> have a suggestion on how to make it more integrated with the ruleset/package
<br>> structure.<br>><br>> At the moment Ruleflow packages are a seperate entity that is merged into a<br>> RuleBase as needed.<br>><br>> Does anyone have any objections if we add the ability to have ruleflow as
<br>> part of a rule Package itself? (thus when that package is added to the<br>> rulebase, all the processes for ruleflow go along with it)? so a ruleflow.rf<br>> file for example becomes just another asset like a drl?
<br>><br>> Kris? thoughts? downsides?<br>> No need to change the current API.<br>><br>> Michael<br></blockquote></div><br>