[rules-dev] RFC: stream concept

[Wolfgang Laun]

On 26 July 2011 21:42, Edson Tirelli <ed.tirelli at gmail.com> wrote:

>
>    Hi all,
>
>    As you all know, we use "entry-points" to represent streams in Drools,
> but in fact, entry points are a much more general abstraction than just
> streams. For instance, they create partitions in the RETE's alpha network,
> they support all Rete concepts like truth maintenance, they share a
> centralized fact handle factory (that is possibly a contention point), etc.
>
>    Event Streams in general can have a much more specialized
> implementation. For instance, as events are immutable,
>

"Immutable" certainly not by a Drools definition? Something with
@role(event) is just a fact, and I can modify an event as required by my
application.


> there is no need for truth maintenance;
>

A fact derived from events could be managed by the TMS - why not? Or do you
mean s.th. else?



> streams should be 100% parallelizable (does this word exist?);
>

If it didn't exist before, it exists now ;-)


> some algorithms like event sequencing can be run before injecting events
> into the main engine instead of injecting and then coordinating back with
> the sequencing algorithm.
>
>    Because of things like the ones above, I was considering creating an
> explicit concept for streams in Drools. They would be a first class concept
> in the engine and would be handled appropriately. They would be orthogonal
> to entry-points, and be used exclusively for events.
>

It's difficult (for me) to see what a "stream" should imply. Can you provide
a concise definition? A "stream" should be for  role event only, and its
facts should be immutable (?) - what else?

Are there any good use cases for these "streams" that cannot be readily
dealt with using events?


>    The other option that we have would be to continue to hide the
> implementation behind the concept of entry-points and to select algorithm
> details by compile time analysis. Although it seems like a simpler solution,
> it has the potential of confusing users
>

Most of the time, the confusion of Drools users stems from the lack of clear
documentation - not from the complexitiy of features.

Cheers
Wolfgang


> that would not know exactly when something is being executed as a regular
> entry point (with TMS, and all the stuff mentioned above) or as a specific
> stream (that has features that would be specific for events).
>
>    Thoughts?
>     Edson
>
>
> --
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> 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/20110727/70ed48de/attachment-0001.html