platform-team/team3.1/operation-participation.html - www.eclipse.org/eclipse - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 <title>Eclipse Platform Operation Participation</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>

 <body>
 <h1>Eclipse Platform Operation Participation</h1>
 <p>The purpose of this document is to present details of the solutions for the
   operation participation scenarios presented in <a href="logical-support.html">Enabling
   Logical Model Integration in the Eclipse Platform</a>.</p>
 <h2>Physical to Logical</h2>
 <p>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.</p>
 <p>It would be beneficial if model tooling could participate in operations that
   could potentially corrupt a model. This participation could take many forms:</p>
 <ul>
   <li>receive pre-notification of an operation that is about to be performed
     <ul>
       <li>notify the user that an operation they are performing may corrupt a
         model</li>
       <li>abort an operation that would be too destructive</li>
     </ul>
   </li>
   <li>participate in the operation itself
     <ul>
       <li>augment the operation is such a way that model consistency is maintained</li>
     </ul>
   </li>
   <li>perform post-operation processing to adjust the model to the change</li>
 </ul>
 <p>There are several complicating factors:</p>
 <ol>
   <li>The set of resource operations that can corrupt a model needs to be identified.
   </li>
   <ul>
     <li>setting file contents and moving or deleting files/folders definitely
       may corrupt a model</li>
     <li>what about creating or copying resources?</li>
     <li>project close</li>
   </ul>
   <li>At what level should the participation take place.</li>
   <ul>
     <li>Higher levels provide more context but are more numerous. Basically, each
       layer would need to provide a participation API for higher layers to use.</li>
     <li>Lower levels are fewer but may not give the entire context of the operation
       (or may not have direct access to a UI context)</li>
     <li>Even if higher level participation is supported, you would want lower
       level hooks
       <ul>
         <li>in case some tooling doesn't provide participation</li>
         <li>two independent models are built on the same resource (although this
           seems unlikely to occur)</li>
       </ul>
     </li>
   </ul>
   <li>There may be multiple models interested in a single resource.
     <ul>
       <li>Determining which models are interested must be efficiently computed.
       </li>
       <li>The case of multiple interested parties, although potentially rare,
         needs to be handled in a reasonable way</li>
     </ul>
   </li>
   <li>Augmenting an operation may result in further operations that again need
     to go through the participation process</li>
 </ol>
 <p>&nbsp;</p>
 <h2>Status</h2>
 <p>Here is the status of this work as of 3.1 M5</p>
 <ul>
   <li>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.</li>
   <li>ResourceMapping/ResourceMappingContext: Initial cut is available in 3.1
     M5 and will be in 3.1 as provisional API.</li>
   <li>Merge Support: Although work has not begun, this area is well bounded and
     well understood. </li>
   <li>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.</li>
 </ul>
 <h2>Open Issues</h2>
 <p>Here are the list of open issues:</p>
 <ul>
   <li><strong>Transaction support</strong>: Some repository may have transaction
     support. It is unclear how this fits in with logical model support.</li>
 </ul>
 <p>&nbsp;</p>
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	<html>
	<head>
	<title>Eclipse Platform Operation Participation</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body>
	<h1>Eclipse Platform Operation Participation</h1>
	<p>The purpose of this document is to present details of the solutions for the
	operation participation scenarios presented in <a href="logical-support.html">Enabling
	Logical Model Integration in the Eclipse Platform</a>.</p>
	<h2>Physical to Logical</h2>
	<p>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.</p>
	<p>It would be beneficial if model tooling could participate in operations that
	could potentially corrupt a model. This participation could take many forms:</p>
	<ul>
	<li>receive pre-notification of an operation that is about to be performed
	<ul>
	<li>notify the user that an operation they are performing may corrupt a
	model</li>
	<li>abort an operation that would be too destructive</li>
	</ul>
	</li>
	<li>participate in the operation itself
	<ul>
	<li>augment the operation is such a way that model consistency is maintained</li>
	</ul>
	</li>
	<li>perform post-operation processing to adjust the model to the change</li>
	</ul>
	<p>There are several complicating factors:</p>
	<ol>
	<li>The set of resource operations that can corrupt a model needs to be identified.
	</li>
	<ul>
	<li>setting file contents and moving or deleting files/folders definitely
	may corrupt a model</li>
	<li>what about creating or copying resources?</li>
	<li>project close</li>
	</ul>
	<li>At what level should the participation take place.</li>
	<ul>
	<li>Higher levels provide more context but are more numerous. Basically, each
	layer would need to provide a participation API for higher layers to use.</li>
	<li>Lower levels are fewer but may not give the entire context of the operation
	(or may not have direct access to a UI context)</li>
	<li>Even if higher level participation is supported, you would want lower
	level hooks
	<ul>
	<li>in case some tooling doesn't provide participation</li>
	<li>two independent models are built on the same resource (although this
	seems unlikely to occur)</li>
	</ul>
	</li>
	</ul>
	<li>There may be multiple models interested in a single resource.
	<ul>
	<li>Determining which models are interested must be efficiently computed.
	</li>
	<li>The case of multiple interested parties, although potentially rare,
	needs to be handled in a reasonable way</li>
	</ul>
	</li>
	<li>Augmenting an operation may result in further operations that again need
	to go through the participation process</li>
	</ol>
	<p> </p>
	<h2>Status</h2>
	<p>Here is the status of this work as of 3.1 M5</p>
	<ul>
	<li>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.</li>
	<li>ResourceMapping/ResourceMappingContext: Initial cut is available in 3.1
	M5 and will be in 3.1 as provisional API.</li>
	<li>Merge Support: Although work has not begun, this area is well bounded and
	well understood. </li>
	<li>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.</li>
	</ul>
	<h2>Open Issues</h2>
	<p>Here are the list of open issues:</p>
	<ul>
	<li><strong>Transaction support</strong>: Some repository may have transaction
	support. It is unclear how this fits in with logical model support.</li>
	</ul>
	<p> </p>
	</body>
	</html>