<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3132" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2>Hi Edson,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2>Sorry if I'm causing more pain and grief than you ever 
intended your original posting to cause.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2>Now I understand (more) the use case for Events I can 
better appreciate your original dilemma. If you need the information to optimise 
the RETE network at compile-time why do you need to perform the check when a 
Fact is inserted; couldn't you have a new ObjectTypeNode that is specific to 
Event classes? If my lack of knowledge is more of a hindrance let me know and 
I'll revert to being a passive observer.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2>Cheers,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=675281409-09112007><FONT face=Arial 
color=#0000ff size=2>Mike</FONT></SPAN></DIV><FONT face=Arial color=#0000ff 
size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><BR>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> rules-dev-bounces@lists.jboss.org 
  [mailto:rules-dev-bounces@lists.jboss.org] <B>On Behalf Of </B>Edson 
  Tirelli<BR><B>Sent:</B> 08 November 2007 15:50<BR><B>To:</B> Rules Dev 
  List<BR><B>Subject:</B> Re: [rules-dev] Determining if a class is an event or 
  not<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><BR>&nbsp;&nbsp; Michael,<BR><BR>&nbsp;&nbsp; The 
  engine *must* know, at rulebase compile time, what classes represent events. 
  When I say it is for optimization purposes, is because events are 
  "light-weight" facts with special characteristics, but that occur in huge 
  volumes, and so, the engine will never scale without knowing they are events. 
  The way we can make the engine aware that a given class is an event may vary: 
  <BR><BR>* we can use some "declaration statement" in the DRL like the ones I 
  described<BR>* we can make the classes implement a markup-interface like 
  Matthias was suggesting<BR>* we can use keywords, like iLog uses, writing 
  "event" in every pattern that represents an event <BR><BR>&nbsp;&nbsp;&nbsp; 
  Besides what I commented in a previous e-mail regarding the markup interfaces, 
  having the declaration statement in the DRL has an additional benefit of 
  making clear to third-parties reading the rules that those are event classes 
  (that carry special characteristics). <BR><BR>&nbsp;&nbsp;&nbsp; The idea here 
  is to discuss exactly the benefits and disadvantages of each approach. 
  :)<BR><BR>&nbsp;&nbsp;&nbsp; []s<BR>&nbsp;&nbsp;&nbsp; Edson<BR><BR>
  <DIV><SPAN class=gmail_quote>2007/11/8, Anstis, Michael (M.) &lt;<A 
  href="mailto:manstis1@ford.com"> manstis1@ford.com</A>&gt;:</SPAN>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
    <DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>I can 
    turn that question around...</FONT></SPAN></DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>If the 
    user has written objects MyFact and MyEvent is it fair to expect them to 
    have to declare it in the DRL?</FONT></SPAN></DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>I don't 
    know what Events are to do in Drools so don't which is the more reasonable 
    approach. Is it just for network optimisation as you say, or will Drools be 
    calling into members?</FONT></SPAN></DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>This is 
    much more interesting than (my) work ;-)</FONT></SPAN></DIV><BR>
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV lang=en-us dir=ltr align=left>
      <HR>
      <FONT face=Tahoma size=2><B>From:</B> <A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:rules-dev-bounces@lists.jboss.org" 
      target=_blank>rules-dev-bounces@lists.jboss.org</A> [mailto:<A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:rules-dev-bounces@lists.jboss.org" 
      target=_blank>rules-dev-bounces@lists.jboss.org</A>] <B>On Behalf Of 
      </B>Edson Tirelli<BR><B>Sent:</B> 08 November 2007 14:54<BR><B>To:</B> 
      Rules Dev List</FONT>
      <DIV><SPAN class=e id=q_1161fe99cf371b70_1><FONT face=Tahoma 
      size=2><BR><B>Subject:</B> Re: [rules-dev] Determining if a class is an 
      event or not<BR></FONT></SPAN></DIV><BR></DIV>
      <DIV><SPAN class=e id=q_1161fe99cf371b70_3>
      <DIV></DIV><BR>&nbsp;&nbsp; Michael,<BR><BR>&nbsp;&nbsp; Yes, the 
      session.insertEvent() API is something other engines (like iLog JRules) 
      have. I initially discarded that idea, but since you mentioned, we may 
      need to reconsider it.<BR>&nbsp;&nbsp; Anyway, the API would solve this 
      part of the problem, but the whole scenario is: <BR>&nbsp;&nbsp; The 
      engine must know at the compile time exactly what classes/interfaces used 
      in rules are events, so that it can optimize the network. That is 
      achievable by using any of the syntaxes bellow (I'm not sure which one to 
      use yet): <BR><BR>import event a.b.c.Foo; (or)<BR>import event 
      a.b.c.*;<BR><BR>or explicit saying:<BR><BR>declare event 
      a.b.c.Foo;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; Once the user declared that 
      something is an event, do you think it is fair/acceptable to force the 
      user to use a different API to insert events into the engine? 
      <BR><BR>session.insert(); for regular facts<BR>session.insertEvent(); for 
      events<BR><BR>&nbsp;&nbsp; []s<BR>&nbsp;&nbsp; Edson<BR><BR>
      <DIV><SPAN class=gmail_quote>2007/11/8, Anstis, Michael (M.) &lt;<A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:manstis1@ford.com" target=_blank>manstis1@ford.com 
      </A>&gt;:</SPAN> 
      <BLOCKQUOTE class=gmail_quote 
      style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Here's 
        my 2 cents - as a non-contributor to Drools codebase ;-)<BR><BR>You 
        could add insertEventFactTypeThingie to the API? Then you need just 
        <BR>check that the class has been declared as an event in the DRL 
        similar to<BR>what must already happen for normal DRL imports. I 
        personally don't have<BR>issue with implementing a marker interface 
        (this is what frameworks like <BR>Hibernate, EJB3 and Spring etc have 
        been imposing for years). What "wiring"<BR>does the POJO need to become 
        an Event for use in Drools? Are you trying to<BR>internalise too much at 
        the risk of making the event mechanism inflexible? 
        <BR><BR>Cheers,<BR><BR>Mike<BR><BR>-----Original Message-----<BR>From: 
        <A onclick="return top.js.OpenExtLink(window,event,this)" 
        href="mailto:rules-dev-bounces@lists.jboss.org" 
        target=_blank>rules-dev-bounces@lists.jboss.org</A><BR>[mailto:<A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="mailto:rules-dev-bounces@lists.jboss.org" target=_blank> 
        rules-dev-bounces@lists.jboss.org</A>] On Behalf Of Matthias<BR>Sent: 08 
        November 2007 13:09<BR>To: <A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="mailto:rules-dev@lists.jboss.org" 
        target=_blank>rules-dev@lists.jboss.org</A><BR>Subject: Re: [rules-dev] 
        Determining if a class is an event or not <BR><BR>Edson Tirelli 
        &lt;tirelli &lt;at&gt; <A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="http://post.com" target=_blank>post.com</A>&gt; 
        writes:<BR><BR>&gt;<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;All,&nbsp;&nbsp; 
        I reached a point where I need to make a design decision 
        and<BR>would<BR>like your opinion about it.&nbsp;&nbsp; Imagine the 
        following scenario:&nbsp;&nbsp; A user has a <BR>domain model like 
        this:package a.b.c<BR>&gt; ;public interface Event { ... }package 
        x.y.z;public class MyEvent<BR>implements<BR>a.b.c.Event 
        {...}&nbsp;&nbsp; Then, in his DRL file he writes:package 
        p.q.r;import<BR>event<BR>a.b.c.* ;&nbsp;&nbsp;&nbsp;&nbsp;rule 
        Xwhen<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Event( ... 
        )then&nbsp;&nbsp;&nbsp;&nbsp;...end&nbsp;&nbsp; So, it is clear that 
        a.b.c.Event should<BR>be<BR>handled as an event by the 
        engine.&nbsp;&nbsp; At runtime, the user asserts an object<BR>of<BR>the 
        class x.y.z.MyEvent into the working memory. Seems clear to me (and 
        <BR>probably<BR>to the user) that MyEvent should be handled as an event, 
        since by DRL<BR>semantics,<BR>&gt; a.b.c.* are all events, and by OO 
        class hierarchy concept, since<BR>a.b.c.Event<BR>is an event, 
        x.y.z.MyEvent is an event too.&nbsp;&nbsp; My question is: how the 
        engine <BR>knows that MyEvent is an event, since it only has the 
        x.y.z.MyEvent<BR>&gt;&nbsp;&nbsp;class as input?&nbsp;&nbsp; The only 
        answer I have is that when the first MyEvent<BR>instance is asserted 
        into the working memory, we must get the class name and <BR>iterate over 
        all event import declarations checking for a match. In case 
        no<BR>one<BR>is found, we need to repeat the process for each interface 
        and each class up<BR>in<BR>the MyEvent hierarchy. Once this process is 
        complete, we cache the results <BR>in<BR>the 
        ObjectTypeConf.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;This may be a quite heavy 
        process to be executed each time a fact of a<BR>different class is 
        asserted in the working memory for the first time, but I<BR>can't think 
        a different user-friendly way to solve the question. 
        <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;The alternatives would be intrusive, 
        IMO, breaking the drools premise<BR>to<BR>work with user-defined POJOs 
        as facts: use anotations to annotate classes<BR>that<BR>are events, or 
        mandate users implement a specific interface for events. 
        <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Any better 
        idea?&nbsp;&nbsp;&nbsp;&nbsp;[]s&nbsp;&nbsp;&nbsp;&nbsp;Edson&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;&nbsp; 
        Edson Tirelli&nbsp;&nbsp;Software<BR>Engineer<BR>- JBoss Rules Core 
        Developer&nbsp;&nbsp;Office: +55 11 3529-6000&nbsp;&nbsp;Mobile: +55 
        11<BR>9287-5646<BR>&gt;&nbsp;&nbsp; JBoss, a division of Red 
        Hat&nbsp;&nbsp;&lt;at&gt;&nbsp;&nbsp; <A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="http://www.jboss.com" 
        target=_blank>www.jboss.com</A><BR>&gt;<BR>&gt;<BR>&gt; 
        _______________________________________________<BR>&gt; rules-dev 
        mailing list<BR>&gt; rules-dev &lt;at&gt; <A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="http://lists.jboss.org" target=_blank>lists.jboss.org </A><BR>&gt; 
        <A onclick="return top.js.OpenExtLink(window,event,this)" 
        href="https://lists.jboss.org/mailman/listinfo/rules-dev" 
        target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR>&gt;<BR><BR><BR>Edson,<BR><BR>I 
        got your striving not to mandate users implement a specific interface 
        for <BR>events. However, why not at least introducing an empty event 
        interface (i.e.<BR>a<BR>marker interface, similar to the Serializable 
        interface in Java) the<BR>user-defined event class(es) have to 
        implement? This way, when inserting a <BR>MyEvent instance, you can 
        simply check whether it implements the event<BR>interface<BR>(by means 
        of 'instanceof'). Moreover, while parsing the import statements 
        of<BR>a<BR>rule file, it enables you to double-check whether all the 
        "event imports" <BR>really<BR>refer to classes implementing the (empty) 
        event interface.<BR>In this regard, for me another question raises: 
        Without making any<BR>restrictions<BR>on the structure for a user 
        defined event class, how do you make sure it has 
        <BR>all<BR>the&nbsp;&nbsp;required attributes of an event (which in my 
        opinion must be a<BR>timestamp,<BR>at least) and how do you access them 
        (necessary for temporal relationships)?<BR>Having said this, in my 
        opinion defining an empty event interface may not be <BR>sufficient; in 
        addition, it must force the user to implement a 
        method<BR>returning<BR>the event's occurrence date (i.e. the timestamp) 
        at least... Or how would<BR>you<BR>handle this 
        issue?<BR><BR>Matthias<BR><BR>_______________________________________________ 
        <BR>rules-dev mailing list<BR><A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="mailto:rules-dev@lists.jboss.org" 
        target=_blank>rules-dev@lists.jboss.org</A><BR><A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="https://lists.jboss.org/mailman/listinfo/rules-dev" 
        target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A> 
        <BR><BR>_______________________________________________<BR>rules-dev 
        mailing list<BR><A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="mailto:rules-dev@lists.jboss.org" 
        target=_blank>rules-dev@lists.jboss.org</A><BR><A 
        onclick="return top.js.OpenExtLink(window,event,this)" 
        href="https://lists.jboss.org/mailman/listinfo/rules-dev" 
        target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR></BLOCKQUOTE></DIV><BR><BR 
      clear=all><BR>-- <BR>&nbsp;&nbsp;Edson Tirelli<BR>&nbsp;&nbsp;Software 
      Engineer - JBoss Rules Core Developer<BR>&nbsp;&nbsp;Office: +55 11 
      3529-6000<BR>&nbsp;&nbsp;Mobile: +55 11 9287-5646 <BR>&nbsp;&nbsp;JBoss, a 
      division of Red Hat @ <A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="http://www.jboss.com" target=_blank>www.jboss.com</A> 
    </SPAN></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>rules-dev 
    mailing list<BR><A onclick="return top.js.OpenExtLink(window,event,this)" 
    href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A><BR><A 
    onclick="return top.js.OpenExtLink(window,event,this)" 
    href="https://lists.jboss.org/mailman/listinfo/rules-dev" 
    target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR 
    clear=all></BLOCKQUOTE></DIV><BR><BR clear=all><BR>-- <BR>&nbsp;&nbsp;Edson 
  Tirelli<BR>&nbsp;&nbsp;Software Engineer - JBoss Rules Core 
  Developer<BR>&nbsp;&nbsp;Office: +55 11 3529-6000 <BR>&nbsp;&nbsp;Mobile: +55 
  11 9287-5646<BR>&nbsp;&nbsp;JBoss, a division of Red Hat @ <A 
  href="http://www.jboss.com">www.jboss.com</A> </BLOCKQUOTE></BODY></HTML>