[rules-dev] Bugs/Problems with 3.1.0M1

[Mark Proctor]

WorkingMemoryFileLogger is still something we need to update. You get 
access to the results with StatelessSessionResults, you don't get access 
to the FactHandles as they are meaningless in a stateless session, you 
can't use them anyway. We may add an internal method to access the 
working memory, i.e. accessible by casting, but I don't really want to 
have a public method for this as your average user will just abuse it.

We use to have user pluggeable conflict resolution strategies, but it 
got removed during some big refactoring, i do intend to add it in before 
4.0 final. If people build useful conflict resolution strategies, we 
will include them - but please do try and base them on existing 
literature if you can, especially for the naming of the strategies.

Mark


Arjun Dhar wrote:
> Mark Proctor <mproctor <at> codehaus.org> writes:
>
>   
>> btw SyncrhonisedWorkingMemory used the same interface as WorkingMemory.
>> StatefulSession just extends WorkingMemory, so the API change for you
>> should be minimal.
>> Mark
>> Mark Proctor wrote:
>>     
>
> Q) ok! ..So how do I use "WorkingMemoryFileLogger" with a StatelessSession and 
> how do I obtain Fact Handles to the facts I asserted?
>
> Feature Requested:
> ------------------
> Q) also, I wish to override the conflict resolution strategy to only have the 
> most significant rule execute and not bother about arranging the rest. Winner 
> takes all strategy. In 4 are you planning on anything for this? Ok, I think 
> this topic deserves a little more respect:
>
> When we create an agenda based on priorities for the rules suited to fire; two 
> things need to be done
>  1. Intelligence to figure out in certain cases what is priority.
> Example: 
> Rain = True <-- More generic Rule
> Party = False
>
> Rain = True <-- More specific rule
> Umbrella = True
> Party = True
>
> ...i've observed that in such scenarios, the rule engine can be intelligent 
> enoug to figure out that a more specific case exists because it is more apt for 
> that situation. Ofcourse GIGO, if the analyst is trying to confuse an engine, 
> thats illogical in the first place. But logic holds here.
>
> 2. When priorities are assigned, the Rule with the highest priority executes 
> firest. But that assumption is incorrect as there can be 3 possibilites:
>  2.1. Only execute the most important rule (Short Curcuit)
>  2.2. Most significant rule, fires first (Like we have when I last checked)
>  2.3. Most significant rule should actually execute last, because we want it to 
> prevail over the results carried out by others.
> ..While 2.3 can achieved in a less sophisticated manner by reversing the 
> priorities 2.1. ... there is no ready made way to achieve 2.1. 
>
> If there is, please let me know. If not, and i build it would you find 
> acceptance in yr next release?
>
> thanks,
> Arjun
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070514/385643ca/attachment.html