[equinox-dev] Re: registry resolution work update

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Rafael and I talked today about a model where the constraints solver is actually ignorant of plugins.  That is, it presents its own data model.  This would allow it to solve constraints between plugins or features.  More specifically here is an outline (ignore the names etc.  This is just psuedo code)

interface IConstrainable {
        String getId();
        IVersion getVersion();
        IPrerequisite[] getPrerequisites();
        boolean isResolved();
}

interface IPrerequisite {
        IVersion getVersion();
        int getMatchRule();
}

interface IConstraintSystem {
/** A representation of a partially or fully solved set of constraints. Able to answer questions 
   about the IConstrainables that are in the system.
 */
        IConstrainable[] getElements();
        void addElements(IConstrainable[]);
        void removeElements(IConstrainable[]);
        IConstraintDelta resolve();
}

With this in mind system startup works as follows

1) read all installed, configured and enabled plugin.xml and fragment.xmls into Collections
2) merge the fragments into the plugins.  Remember but ignore any fragments which have no base plugin (either plugin is missing or version is missing)
3) Derive IConstrainables from the plugins.  This could be a noop if PluginDescriptor implemented IConstrainable but the constraint system should be small in total footprint and we want to put the registry on disk so separating the two would be good.
4) call
        IConstraintSystem system = new IConstraintSystem();
        system.addElements(<elements from step 3>);
        IConstraintDelta delta = system.resolve();
5) given "system" iterate over the elements and build a registry structure containing the resolved plugins/fragments and lists the unresolved plugins/fragments.
6) link extensions to extension points.

For incremental additions/removals we add/remove them to/from the system and then resolve().  The resultant delta is used to update the registry.

Note that enabling or disabling a plugin maps onto add/removeElement respectively.

Regarding group operations...  If you do the operations individually you still have the same problem.  You get halfway though a list of things and something fails.  Is it all or nothing?  How do you back out?  What do just press on? etc etc.

The essential difference is whether or not you think that these operations can "fail".  As per our previous discussions I think they cannot.  Changing something that makes other things become unresolved etc is acceptable/desireable.  As for deactivation, what cases do you see where a plugin could fail to be deactivated? (note I am distinguishing deactivation from clean up).

Jeff

Keith Kimball@IRIS 05/13/2003 06:40 PM

To:        Rafael Chaves/Ottawa/IBM@IBMCA@IBMUS         cc:        Jeff McAffer/Ottawa/IBM@IBMCA         Subject:        Re: registry resolution work updateLink

Hi Rafael,

Great news on your side.

Before I tell you want I've been doing, let me reassure you that our changes will not conflict. I've also been working on the RegistryResolver but only to refactor it and NOT change any internal algorithms. 

The good news is that I have it broken into 3 pieces - the portion which resolves the dependencies, the portion which trims the registry, and the portion which links the extension and extension points together. You've been focused on the first.

I If you recall, after your done with dependency resolution, plugins are marked as either enabled or disabled. These are actually bad names as they should be resolved or unresolved. Instead of having the resolver trim the disabled plugins, I now have PluginRegistryModel do it and in the process store them in a list. These are really the plugins which failed resolution but Jeff wants them presented the next time we do registry resolution.

So now PluginRegistyModel.resolve does the following:

• Calls you to resolve dependencies
• Trims the registry itself but maintains the list of trimmed plugins.
• Calls you to link the extensions and extension points.
  
  The other thing I plan on doing is to change the Resolver to take a list of plugins and a list of fragments rather than a registry. If you look at your code, the registry is only used to getPlugins and getFragments. Thus I could create a list of Plugins and Fragements, present them to you, see the result, and THEN decided whether or not to proceed with the operation.
  
  I've also been working in PluginDecriptor which is a lower level routine to properly track the state of RESOLVED plugins.  These states seem to be
  
                  Inactive or Deactivated (hasn't been referenced)
                  StartError (attempted activation but the start method failed - currently called disabled)
                  ActivePending (in the process of being activated)
                  Activated (active)
  
  I absolute hate the group model. I don't know what it means to say disable(plugin-list). Is it an all or nothing operation? Can the plugin's be in any state? What happens if it causes other plugins to go unresolved - do I have to deactivate them? What happens if I can't deactivate them? Can part of the operation succeed? The good news is that we can play with this and decide on a policy later on.
  
  Back to work and thanks for mailing me. I'm taking a 3 day weekend (Sat-Mon) and will be offline.
  
  Great work!!!!
  Keith
  
  
  
  
  Rafael Chaves/Ottawa/IBM@IBMCA

  05/13/2003 04:15 PM

  To	Keith Kimball/Westford/IBM@Iris@IBMUS
  cc
  Subject	registry resolution work update

  
  
  
  
  
  Hey Keith!
  
  Sorry for taking so much time for doing it, but I think now it is a better time to update you with the results of my registry resolution-related work here.
  
  I spent the first week learning about constraint systems, constraint solvers and porting an existing DeltaBlue implementation (the incremental constraint solving algorithm we are using right now) in Smalltalk to Java. Mostly manual work...
  
  The second week I spent trying to figure out how to solve our problem (plug-in registry incremental resolution) by modeling constraint systems supported by DeltaBlue (no cycles, one output variable per constraint). So far I have been able to map a plug-in registry automatically to a constraint system, and to solve the system using DeltaBlue. We still have some issues to look at, namely batch additions/removals of constraints (the default DeltaBlue behavior is to update the system each time an individual constraint is added/removed, and that is overkill), and a better story for handling conflicts (right now we let plug-ins that will not be resolved because they generate conflicts to affect the outcome of the resolution - and they shouldn't).
  
  And what about you? How are things going?
  
  Please let me know if you have any questions about the work I am involved with, or if you have any suggestions in the way we should conduct our work (for instance, maybe you would like that there were more interaction).
  
  Regards,
  
          Rafael