[jboss-jira] [JBoss JIRA] (JBRULES-3514) Add support to event sequencing

Wed May 23 12:00:18 EDT 2012

    [ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695156#comment-12695156 ] 

Edson Tirelli edited comment on JBRULES-3514 at 5/23/12 11:59 AM:
------------------------------------------------------------------

Wolfgang, thank you for all the valuable feedback. My notes:

* *(WL1)*, *(WL2)* : added to the document.

* *(WL3)* : an event tuple is not an event by itself, but share some of the same properties as events. Clarified that on the document, let me know if it is still confusing.

* *(WL4)* : added your suggestions, clarified your concerns and added the operators ~> and \\.

* *(WL5)* : not sure if I understood your concern, but if the user needs anything out of the ordinary, he can always revert to explicit rules creating and inserting the events. With pattern repetition, the user is usually not interested in the individual events as they are most of the time repetitions, but I added a property to the Tuple type to return the list of matched events in case the user wants to keep them around.

* *(WL6)* : (a) agreed and fixed. (b) the properties are just synonyms to the corresponding indexes making them easier to read, so I would like to keep them around. (c) just an explicit access to the iterator, but I agree the Tuple should be Iterable in order to enable the use of the simplified for loop syntax.

* *(WL7)* : this is a discussion I've been having with the rest of the team. The reason I am advocating that "every" should be the default is because we are unifying CEP and BRE concepts and our heritage is BRE. In BRE, A() means "every A". Now imagine that you have an event A and a fact X. If every is not the default, the user writing

{code}A() and X() {code}

Would have to read that as "any A with every X"? This is totally confusing IMO. The default should be the same, does not matter if one is dealing with events of regular facts (after all, we define events as facts with additional semantics). I agree that it makes no sense to match every combination of SxE, so your event would be defined as:

{code}event X as A() -> first C() end{code}

If you compare to your original suggestion, it is just a matter of which keyword you add:

{code}event X as every A() -> C() end{code}

I am open to further discussions on this, but at the moment, I feel the confusion of having different defaults for events and facts trumps the other arguments...

      was (Author: tirelli):
    Wolfgang, thank you for all the valuable feedback. My notes:

(WL1), (WL2) : added to the document.

(WL3) : an event tuple is not an event by itself, but share some of the same properties as events. Clarified that on the document, let me know if it is still confusing.

(WL4) : added your suggestions, clarified your concerns and added the operators ~> and \\.

(WL5) : not sure if I understood your concern, but if the user needs anything out of the ordinary, he can always revert to explicit rules creating and inserting the events. With pattern repetition, the user is usually not interested in the individual events as they are most of the time repetitions, but I added a property to the Tuple type to return the list of matched events in case the user wants to keep them around.

(WL6) : (a) agreed and fixed. (b) the properties are just synonyms to the corresponding indexes making them easier to read, so I would like to keep them around. (c) just an explicit access to the iterator, but I agree the Tuple should be Iterable in order to enable the use of the simplified for loop syntax.

(WL7) : this is a discussion I've been having with the rest of the team. The reason I am advocating that "every" should be the default is because we are unifying CEP and BRE concepts and our heritage is BRE. In BRE, A() means "every A". Now imagine that you have an event A and a fact X. If every is not the default, the user writing

A() and X() 

Would have to read that as "any A with every X"? This is totally confusing IMO. The default should be the same, does not matter if one is dealing with events of regular facts (after all, we define events as facts with additional semantics). I agree that it makes no sense to match every combination of SxE, so your event would be defined as:

event X as A() -> first C() end

If you compare to your original suggestion, it is just a matter of which keyword you add:

event X as every A() -> C() end

I am open to further discussions on this, but at the moment, I feel the confusion of having different defaults for events and facts trumps the other arguments...

> Add support to event sequencing
> -------------------------------
>
>                 Key: JBRULES-3514
>                 URL: https://issues.jboss.org/browse/JBRULES-3514
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api, drools-compiler, drools-core
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.5.0.Beta1
>
>
> The purpose of this ticket is to centralize the discussions regarding the implementation of event sequencing as detailed in the wiki page at:
> https://community.jboss.org/wiki/EventSequencing
> The highlevel discussions can be added to this ticket while individual sub-tickets will be created for the implementation of each sub-feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira