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

[Wolfgang Laun]

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>