Note: Extension and Extensions Points will be added later
RegistryResolver will be changed so
it operates independent of a registry (i.e., arguments are a list of
plugins and fragements) and such the functions are resolving
dependencing, trimming the registry, and matching extensions and
extension points are independent.
RegistryModel will be changed to
maintain two additional lists - unresolved and disabled plugins.
Currently after resolution, the registry only contains resolved plugins.
Startup registry resolution will
occur as today except that instead of discarding unresolved plugins,
these will be added to the above mentioned list.
Plugins get on the disabled list as
a result of the new disable method or as a result of discovery after
registry resolution (i..e, some sort of "install" method).
Enable(plugin[]) will occur as
follows:
RegistryResolver will
be called with a list of plugins consisting of currently resolved,
currently unresolved, and the plugins to be enabled. These will be
partitioned into resolved and/or unresolved plugins. Note, that this
does NOT effect the current registry nor other threads.
The result of
resolution is compared against the current registry. If any currently
resolved plugins or plugins explicitly named in the enable command will
be resolved, an error is raised.
The newly resolved
plugins are added to the active registry (and removed from the disabled
list) in depth-first order. This can be done without effecting other
threads and the registry is always consist.
Disable(plugin[]) will occur as
folows:
RegistryResolver will
be called with a list of plugins consisting of currently resolved
plugins minus those being disabled.
The result of
resolution is compared against the current registry and if no plugins
become unresolved, the disabled plugins are "deactivated and prohibited
from activating" in breath-first order and then moved to the
disabled list.
Plugins named in the
disable method which are currently unresolved are moved to the disabled
list.
An enable(empty-array)
is performed to catch unresolved plugins which become resolved as a
result of the disablement.
Note: I would have preferred
to have done the disablement in a single step but can't determine an
order to add/remove plugins to the registry which keep it consist when
the disablement of certain plugins result in other plugins becoming
resolved.
Note: One other option is one you
know the state you want the registry in, to someone disable access to it
and then make the changes as a single atomic operation. I've done the
opposite - figure out the final state and find small steps which get
there without making the regisrtry inconsistent.
Milestones
Milestones
Enable a plugin without dependencies in either direction. This is
the easiest spike we can come with.
Enable a plugin without dependencies but other plugins optionally
depend upon. This allows us to demonstrate a operation which fails,
enabling of a plugin, and then the same operation succeeding.
Enable plugins with dependencies in both directiions. This is the
real meat.
Reject enablement due to the potential for other plugins to
become unresolved
Deal with Fragments
Deal with Disablement.
Design extension and extension point milestones. One thought is
to have class such as DynamicExtensionPoint with extends ExtensionPoint
and set of conditions which allow enablement and disablement
Work on use cases considering groups of plugins. One idea would
be to attempt to enable an entire feature by using the enable/disable
primitives.
Milestone Deliverables
Updated Design
Code
Examples
New milestone List
Issues
Open Issues
Extension points.
Verifying that the dynamic registry is thread safe.