Eclipse Platform Operation Participation

The purpose of this document is to present details of the solutions for the operation participation scenarios presented in Enabling Logical Model Integration in the Eclipse Platform.

Physical to Logical

In Eclipse, there can typically be many different model spaces. Many of these can be considered layers on top of the Platform resource model, in the sense that the elements that constitute a model are persisted in Platform resources. When operations are launched from model elements or are performed by model tooling, consistency of the model can be maintained. However, given the presence of multiple models and multiple layers, it is always possible that operations are launched from elsewhere (i.e. the tooling of other models) and are not aware of all the models that could be affected. For instance, deleting a file from the Resource Navigator may corrupt a higher level model that was persisted, at least partially, in that file. In this case, all the model tooling can do is make a best effort at cleaning up and notify the user of any inconsistencies that may exist.

It would be beneficial if model tooling could participate in operations that could potentially corrupt a model. This participation could take many forms:

• receive pre-notification of an operation that is about to be performed
  • notify the user that an operation they are performing may corrupt a model
  • abort an operation that would be too destructive
• participate in the operation itself
  • augment the operation is such a way that model consistency is maintained
• perform post-operation processing to adjust the model to the change

There are several complicating factors:

1. The set of resource operations that can corrupt a model needs to be identified.
• setting file contents and moving or deleting files/folders definitely may corrupt a model
• what about creating or copying resources?
• project close
2. At what level should the participation take place.
• Higher levels provide more context but are more numerous. Basically, each layer would need to provide a participation API for higher layers to use.
• Lower levels are fewer but may not give the entire context of the operation (or may not have direct access to a UI context)
• Even if higher level participation is supported, you would want lower level hooks
  • in case some tooling doesn't provide participation
  • two independent models are built on the same resource (although this seems unlikely to occur)
3. There may be multiple models interested in a single resource.
   • Determining which models are interested must be efficiently computed.
   • The case of multiple interested parties, although potentially rare, needs to be handled in a reasonable way
4. Augmenting an operation may result in further operations that again need to go through the participation process

Status

Here is the status of this work as of 3.1 M5

• Generic Views: This needs to be driven by model owners with help from Platform committers. Until model teams step forward and dedicate resources to this problem, it is unlikely that work will progress.
• ResourceMapping/ResourceMappingContext: Initial cut is available in 3.1 M5 and will be in 3.1 as provisional API.
• Merge Support: Although work has not begun, this area is well bounded and well understood.
• Physical to Logical: This area is not yet well understood or well bounded as participation in operations can happen at multiple levels and involve multiple models. More design work is required before a solution can be proposed.

Open Issues

Here are the list of open issues:

• Transaction support: Some repository may have transaction support. It is unclear how this fits in with logical model support.