Re: [rules-dev] Why are fundamental API functions not part of "stable"?

Apart from the considerations concerning of the "old user base", I could very well imagine that exposing certain technical implementation-dependent details is to be avoided. Therefore, I emphasized the point that there is a "stable" Activation and an access to Agenda. All that's missing is a getter for the current conflict set. I doubt very much that you'll do away with that in near or far future.

I'm currently developing a general purpose event-logging and peek-into-the-engine package, so I think this constitutes a valid "use case", in the sense you wrote. -W On 09/08/2010, Mark Proctor<mproctor(a)codehaus.org> wrote: > On 09/08/2010 09:58, Wolfgang Laun wrote: >> Trying to provide some debugging functions, I find that >> org.drools.runtime.rule.WorkingMemory (a "stable" interface) lets you >> retrieve >> org.drools.runtime.rule.Agenda (another "stable" interface). But this >> one does not provide access to the current set of Activation objects. >> >> In contrast to this, org.drools.Agenda, which is part of the >> "unstable" Core API, does provide Activation[] getActivations(). > We plan to refactor the entire of drools-core and drools-compiler to > reflect drools-api more, so it'll all change. We couldn't do this in one > go, as many people where already using those interfacaes and > implementations; including some JBoss projects. > > So instead we decided to introduce a new cleaner api that is knowledge > oriented, rather than rules oriented, and have that wrap the old api. So > that we could move forward with a new api, while not upsetting any of > our old user base, giving them time to move across. > > We have taken a very conservative approach with drools-api minimising > what we expose. We instead prefer to wait for valid use cases to > determine what we expose, rather than exposing wait for those use cases > to arise. The reason for this is that the more you expose the harder it > is to change a library over time, due to backwards compatability. So the > conservative aspect gives us more flexability in the long run. > > I also have plans around agenda-groups, ruleflow-groups and other types > of groups. I want to completely redesign the concept here to something > more consistent and uniform and also more powerful and flexible. So > again I'm reluctant to expose things, that might stop us making those > changes. > > Mark >> Since there is org.drools.runtime.rule.Activation in the "stable" >> part, why is it not possible to retrieve the current activations by >> just using the "stable" API? I would think that concepts such as >> "agenda" and its current set of activations are here to stay. What >> should one do when one wants to implement support functions for Drools >> applications that should have long term stability?? >> >> Best >> Wolfgang >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev