Bug 482993

Description Pierre-Charles David 2015-11-25 05:39:06 EST

For bug #482528 on properties view, part of the work (the actual views rendering) will be handled by code which resides in another project (EEF). That code will need to evaluate interpreted expressions defined in Sirius VSMs. We don't want to reproduce the existing Sirius APIs on the EEF side (and write and maintain all the dumb translation code between the two sides), and we can not make EEF depend on Sirius itself (which would cause a dependency loop).

A possible solution is to extract such an API from what exists already in Sirius in a separate plug-in (or plug-ins) that, while they live in the Sirius project, do not actually depend on the Sirius core.

This will be the opportunity to modify the existing Sirius API with long-needed improvements (e.g. in the area of variables management).

The current plan (open to discussion) is to provide:
* a new API defined in new Sirius plug-ins with minimal dependencies (ideally just EMF, maybe Guava; that was enough for the whole AQL implementation so it should be enough for us too).
* an implementation that translates the new API to the old one (IInterpreter);
* a way to obtain such a "wrapper implementation" from a Sirius session.

For bug #482528, this means the Sirius code which hands EEF the views description will also give it an implementation of the new API which is backed of by the existing Sirius interpreter (with all the languages supported there). EEF will only need to depend on the new API (not the wrapper implementation).

Separately from the work on #482528, we'll progressively rewrite all the Sirius code which uses the current/old IInterpreter API to use the new one instead, refining it in the process. Once this is done, we'll deprecate the old API, expose the new one, dropping the wrapper implementation for more direct ones (one for each supported language).

Given this plan, the goal of this new API is not only to break a dependency cycle with EEF, but also to fix/improve the problems with the existing API (cumbersome and error-prone variable management, inconsistencies between languages in coercion rules, lack of feedback on interpretation result, no support for query preperation/compilation...).

As mentioned above, this is what I have in mind right now, but almost all of it is open to dicsussion. The only immediate need is for EEF to be able to evaluate queries defined in Sirius VSMs without depending on the Sirius platform itself.