[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Re: registry resolution work update


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: