Re: [incquery-dev] IPatternMatch refactoring

[Ábel Hegedüs <abel.hegedus@xxxxxxxxxx>]

Hello all,

after an internal discussion, we decided, that the EVM core can be EMF-IncQuery independent and allow activations and rules that work on other atoms (IPatternMatch), events (MatchFound/Lost/Updated) and event handlers (IMatchProcessor).

This change should happen in the near future, until that time, hopefully the CEP development can continue without this.

Cheers,

   Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics

On 18 April 2013 16:50, <bergmann@xxxxxxxxxx> wrote:

Hi,

-----incquery-dev-bounces@xxxxxxxxxxx ezt írta: -----

Can't we hide away all these behind a facade called EventSource{Specification|Instance|...} or something, so that we do not need multiple RuleSpecification and RuleInstance classes? 

We can, we should, we will. Can you elaborate on your idea?

How about this:

eventSourceSpecification may be a MatcherFactory/QuerySpecification (or a wrapper around it), or alternatively something that encompasses a complex event specification 

EventSourceInstance eventSourceInstance = eventSourceSpecification.get(IncQueryEngine) // this is specific to an engine, e.g. a Matcher (or a wrapper around it), or whatever its analogy is in CEP

eventSourceInstance.addUpdateListener(listener); // wraps matchUpdateListener... possibly also element updates?

listener will receive callbacks characterized by (a) an ITuple, (b) a transition/action token that can be interpreted by the ActivationLifeCycle to move to a new state. In case of a matcher, this is appear/disappear (and update?), while for CEP, it may be "happen" or something else characteristic to CEP.

Will this work? I have no idea what kind of internal impulses CEP aims to provide.

Cheers

Gaben

_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/incquery-dev