Re: [rules-dev] RFC: stream concept
On 27 July 2011 15:13, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
Hi Wolfgang,
Thanks for the feedback. My comments.
2011/7/27 Wolfgang Laun <wolfgang.laun(a)gmail.com>
> On 26 July 2011 21:42, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
>
>
Drools (and most CEP products) do not enforce immutability because we
are dealing with "representations of events" and not the events themselves.
Representation of events are usually subject to data enrichment
Of course, this is what I was thinking of, e.g., the possibility of adding
flags such as "isProcessed", which greatly simplifies certain apps.
In such scenarios, TMS for events become just an overhead.
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?
>
A fact derived from events exclusively would be an event and again
immutable.
Again, "data enrichment".
Or, a derived event that I want to be retracted automatically when the
"causing" events drop out of the system due to expirey or whatever.
If the justification is immutable, there would be no need for TMS. On the
other hand, if a justification contain non-events as part of it, it
could be
mutable, and in this case the justified fact should not be modeled as an
event. If it is not an event, TMS should apply. The good thing about we
discussing this is that it made me realize that some users might not be so
strict when modeling their systems, and maybe instead of disabling TMS for
"streams of events", this should be a per object type configuration?
So it seems.
> 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?
>
Streams, from a user's perspective, are just a sequence of events that are
channeled into the system, exactly like entry-points, but specialized for
events. I am not convinced we should create this concept nor am I convinced
that we should continue using entry points. The use of streams would only
make explicit to users that they are exclusive for events (you can use any
type of facts in entry-points) and the algorithms behind the scene are
exclusive for events (entry points, if used like that, would select
algorithms based on heuristics, transparently to users).
If you have entry point declarations you might as well add fact types that
are permitted for this stream:
entry-point Stream1 # for all types
entry-point Stream2 for offHook, onHook # permits just these 2
From offHook and onHook being events, you know that Stream2 is a
"Stream"
entry-point.
Wolfgang
Attachments:
- attachment.html (text/html — 5.3 KB)