Description Cedric Brun 2016-06-22 05:04:49 EDT

During EclipseCon France Akos demonstrated an experimental refresh algorithm which was fully incremental thanks to VIATRA's capabilities.

Making the refresh algorithm swappable at the Sirius level would ease such initiatives/experiments and could even, in fairly extreme use cases be usefull to get more performances with an implementation specificaly tuned to a specific diagram.

As of now we already have an API which is quite close to that:
org.eclipse.sirius.diagram.business.api.refresh.IRefreshExtension with 

void beforeRefresh(DDiagram dDiagram);
void postRefresh(DDiagram dDiagram);

methods. I'd like to extend it to have an:

 boolean aroundRefresh(DDiagram dDiagram);

method (through a specific interface in order to keep the API compatible). If an implementer returns true then Sirius don't do its own refresh.

The open question is what happens when several extensions are provided for a given diagram.  I see two alternatives:

a°) Sirius calls every one and if at least one returned true it won't trigger its refresh
b°) Sirius calls each one and stops as soon as one returns true: this looks randome to me as the extension point don't have any kind of ordinal/priority mechanism.

Considering that it's a case which is unlikely to happen anyway I would go for a°), any opinion against?