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

[Mark Proctor]

  On 09/08/2010 16:11, Wolfgang Laun wrote:
> 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.
For now you can cast and unwrap any drools-api interface and get the 
legacy concrete implementation that you need. We are aiming for 5.2 for 
october, so we can look into exposing some more things then.

CRS is definitely something I want to change. I don't like the idea of a 
global agenda that specifies a single CRS. I want to investigate a more 
general purpose group concept that the user can have more control over; 
so we might have a CRS per group... I don't know yet, at the moment it's 
just ideas floating around in my head :)

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