Re: [incquery-dev] engine life-cycle listener

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

Hello all,

after an internal discussion, we decided on the following:

- deprecate deltaMonitor on Matcher

- move matchUpdateListener registration to Engine

- introduce modelUpdateListener on Engine (using the ChangeLevel variant)

- introduce lifecycle listener on Engine

- introduce managedEngineListener on EngineManager (only initialization event is provided)

New feature request:

- registerChangeListener on a given EObject in IQBase which will callback when any attribute or reference changed. This should be used instead of EMF data binding in the EVM for attribute monitor.

These changes will be implemented in the api_refactor0.7 branch, which will also be used for the other refactor tasks.

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 15:41, Ábel Hegedüs <abel.hegedus@xxxxxxxxxx> wrote:

Hi,

TL;DR model updates, manager events, naming games, how many listener interfaces should we have and where?

for the UPDATE part:

- I included it in the "life-cycle" interface partially because the idea of removing the update callback from matchers was already mentioned in the issue, and partially because I felt that it is part of basic set of events that are engine-wide.

- Also, the model/index/matchset events are not just a "range of events" they are in a very precise relation (matchset update includes index update includes model update). Although this may be invalidated by introducing weak relations (e.g. date > currentDate), where model and index changes may not be available.

For the IncQueryEngineManager part:

- we can add an event listener to the manager as well, although this was not initially part of the issue

For the naming of events:

- I think it is important that the name somehow signifies that the call happens before an event has occurred (dispose), or after (wipe, taint, update). This may be solved by calling dispose after we dismantled the engine, but that means on the one hand that users cannot make a last call to get matches from existing matchers, on the other hand, they can reinitialize an engine if they want...

To sum up my view of the situation, the following events are interesting for ADVANCED users in the different objects of EMF-IncQuery:

- engine manager: managed engine initialization, removal (although unmanaged engines should be private and managed engines are not disposed/removed, and we don't know when the weak reference is GCed, or do we?)

- engine: taint, wipe, dispose, matcher added

- matcher: match found/disappeared

- incrementality: model changed, index changed, match set changed

IF we use one listener interface for each of the first three levels, why shouldn't we also create a single interface for the fourth level? As you can see, I accept that the engine and the "incrementality" levels can be separated.

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 10:42, <bergmann@xxxxxxxxxx> wrote:

Hi,

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

Anyway, what about "afterUpdate" listeners? Shouldn't they also be moved from the Matcher to the Engine? Or are they going away? 

They should be deprecated or removed, along with after wipe callbacks.

Is "matchSetChanged" going to be plagued by the same caveats as "onMatchUpdate" now?

No, it is plagued by different caveats. Namely, you have no idea which match sets have changed and how.

The rest:

- If not existing yet, I suggest to add two new callbacks to IncQueryEngineManager: 

-- "engineInitialized", as this is the point after which any component aware of the IncQueryEngineManager can access IncQuery's features through the engine

-- "engineRemoved"

This is getting Viatra-ish :) But I can see your point.

- change "engineDisposeCalled" to "engineDisposed"

Or engineDisposing() ?

Finally, an idea probably for the future: is there a way to "deconstruct" a single matcher and remove it from an engine? 

No, not currently.

If yes, there should be a callback method for signalling the removal.

Does it make sense to add it now, anticipating a future extension of functionality?

Cheers,

Gaben

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