From: hansgilde <hgilde@...>
Subject: [CEP-Interest] Re: How would you solve this simple problem?
To: CEP-Interest@yahoogroups.com
Date: Tuesday, January 6, 2009, 4:16 PM

So in all this, there seems to be exactly one piece classification
that comes with any kind of real theory on why it matters.

On one hand, we might interpret the requirements such that we need to
be able to know any fact about price of any symbol during any period
of time. In this case, there is no choice but to keep all ticks (or
something that is pretty much equivalent to keeping all ticks).

On the other hand, we might interpret the requirement to maintain a
single boolean flag, updated every clock tick, indicating whether for
the previous 5 minutes worth of clock ticks, the price had been above
the particular hard coded level for the particular hard coded symbol.
Similarly we might infer that whenever the flag switches from false to
true, we will need to send out a message. In this case, storing the
(price) ticks is not even helpful.

And in between, we have a variety of possible requirements for ad-hoc
querying and eventing. Each will have certain requirements for state
storage and real-time detection.

Other than this classification, what is the point of caring if
something is CEP, EP or none of the above? In other words, what
practical (or even theoretical) benefit comes from understanding that
one problem is EP and another problem is not?

So what if a problem isn't EP? So what if it is?

And before anyone says it, the answer is not that a non-EP problem
naturally should be solved with a high speed database. Every problem
should be solved by exactly the solution that is most cost effective
over the long term. And even for ad-hoc queries, that is not always a
high speed database.

So again, what exactly would be the benefit to agreeing that one
problem is EP and another problem is not? Could one not eliminate a
lot of needless worry by simply discussing how one type of solution
would solve a problem, compared to how another type would?

--H

--- In CEP-Interest@ yahoogroups. com, Peter Lin <woolfel@... > wrote:
>
>
> I'm enjoying this discussion.
>
> anyone else notice that a slight change in the semantics of the
patterns ends up changing the problem? Phrased one way, the problem
becomes temporal queries for existential patterns. Changed slightly
and it becomes EP problem.
>
> Don't know if anyone else thinks this, but the problem to me is how
Luis translates english to logic. Depending on the semantics of the
english language they use, the translated result may be incorrect.
>
> to me, the question isn't "is this problem a CEP problem?" the real
question is "what's the user's intent and how do we express it
accurately so a program can translate it correctly?"
>
> peter
>
> --- On Tue, 1/6/09, Brian Connell <brian@...> wrote:
> From: Brian Connell <brian@...>
> Subject: Re: [CEP-Interest] Re: How would you solve this simple
problem?
> To: CEP-Interest@ yahoogroups. com
> Date: Tuesday, January 6, 2009, 12:56 PM
>
>
>
>
>
>
>
>
>
>
>
> Tim,
>
>
>
> > Of course this is an event processing problem.
>
> > You just did not word it in a way to make it sound like one for
the
>
> > EP crowd, LOL:
>
> Is this just an obtuse way of agreeing that the problem as posed
isn't
>
> an event processing problem without seeming to agree? :-)
>
>
>
> > Event A: "Company X stock actions priced above $70 during any
moment
>
> > of the last 5 minutes"
>
> Being pedantic, this is a "Capital Markets" problem. More
>
> importantly, it's different to the problem posed by Luis.
>
>
>
> > In detecting security issues the same is also true:
>
> >
>
> > Event B: "Login from IP address X during any moment of the last 3
>
> > weeks before Login from IP address Y"
>
> To rephrase to put it on a par with the problem as posed by Luis:
>
> "Was the user logged in anytime during the past 5 minutes"
>
>
>
> Be aware, there may not have been any events pertaining to the user
>
> over the past 5 minutes. Or there might have been lots. Or none
for
>
> a week...
>
>
>
> > Event C: "Router X down 5 minutes before Application Y goes down
and
>
> > Application Y down 10 minutes before Application Z alarm."
>
> Nope. To rephrase so that it is relative to the problem posed by
Luis:
>
> "Was AppY down anytime within 10mins before AppZ alarm and if so,
was
>
> Router X down anytime within 5 minutes before AppY failed"
>
>
>
> > If vendor software can't detect these types of relatively simple
>
> > scenarios, then how can you build more complex ones?
>
> Can I suggest a high speed database to store the set of events you
>
> will require to satisfy any ad-hoc queries you might have?
>
>
>
> Brian
>