<br> Barry, <br><br> Yes, your understanding matches mine.<br><br> The decision to make timestamp and duration constant is due to the many side-effects that making them mutable bring, as you guessed. I really want to do the next step and allow mutable temporal properties, but that requires much more research, as it involves all kinds of temporal operations, including clock management and behavior implementations (like sliding windows).<br>
<br> Sorry, but with current version, no easy solution for that. If we can get a few people interested in helping with the development of these features, we could organize a task force to research and implement this. Anyone interested in joining?<br>
<br> Edson<br><br><div class="gmail_quote">2010/4/15 Barry Kaplan <span dir="ltr"><<a href="mailto:groups1@memelet.com">groups1@memelet.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
If I understand you correctly Edson, you have provided a better description<br>
to solution 1) in my post above.<br>
<br>
This works to a degree but leaves a bit to be desired. For example when<br>
correlating instant events as "during" the interval events (ie, startX,<br>
endX, eventX) those correlations cannot simply use "during", because there<br>
may be no eventX yet (ie, endX has not yet occurred).<br>
<br>
This requires patterns of the form:<br>
<br>
instant: InstantEvent<br>
beginX: BeginX<br>
(or (and instant after beginX<br>
not endX(id == beginX.id)<br>
instant is during eventX(id == beginX.id)<br>
<br>
Which like I said gets messy.<br>
<br>
Again, if the @timestamp and @duration were not stored in the fact handle<br>
and could be altered via a working-memory update then "instant is during<br>
eventX" would work in all instances. The trade off is that it would make the<br>
drools internals much more complex as behaviors scheduled based on<br>
@timestamp and @duration would need to be modified according on a wm.update,<br>
along with all race conditions that would entail.<br>
<br>
It could also be argued that modifying an event's timestamp smells for<br>
purity reasons. But that would depend the perspective you take. Some events<br>
unfold over time (hence the modeling construct of using startX, endX,<br>
eventX). So a counter argument might be that a CEP engine should have first<br>
class support events of this nature.<br>
<font color="#888888"><br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p721426.html" target="_blank">http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p721426.html</a><br>
</font><div><div></div><div class="h5">Sent from the Drools - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>