equinox
dynamic plugins > work items
|
|
All the items listed below will lead to the discovery of "use cases" and "good
practices" that should consolidate the "how
to be a good dynamic plugin". Moreover, it could also be interesting to
build a list of recommandations, data structures, etc. for common use cases
(e.g. caches)
- Plugin deactivation mechanism -- Pascal, Jeff, Mel
- Basic notification mechanism;
- API review;
- addition of the "dynamic" notion
- Deactivation use case
- Expected behaviour of the UI plugin in reaction to the deactivation of any plugin (should any open view be closed?, Should the UI plugin do post-cleanup like veryfing the deactivated plugin
removed its listeners, menu entries, etc.?)
-- Woody
- Deactivation of the UI plugin: Study the implication of the deactivation of the UI plugin (or at least
of its subparts). For examples, how do we deal with decorators?
- Expected behavior of the Resource plugin in reaction to the deactivation of any plugin:
See an initial document by JohnA. and Pascal
- Deactivation of the resources plugin
- Deactivation of higher level plugin (user plugins / team, pde.ui, jdt.ui, jdt.launching, ...) -- Pascal
The approach here is to build bigger and bigger example up to the point
in order to identify patterns and practices that can prevent plugins from
begin deactivated, and then ends up by the deactivation of the plugins
listed in the item title.
- Framework for post-plugin cleanup, in case where plugins do not cleanup
correctly
- Here we should provide plugins one or several mechanism that ease the
indentification of classes that might have been left over by a plugin
being deactivated.
- Optimization of the plugin deactivation mechanism, API review
- Thanks to the result of the previous study we will be in a good position
to think about various optimization that can be made in the notification
mechanism.
- Deactivation triggering
- How does the plugins get deactivated: user explicit granularity (one
plugin, any plugin, feature), background thread?
- Strategies for backward compatibilty
Do we need any convertion or instrumentation tool?
Although the disablement feature will greatly benefits from plugin deactivation,
we think it make more sense for the user point of view to be studying enablement
first.
- Making the plugin registry dynamic -- Keith
- Study of an incremental algorithm
- Modification of the notification mechanism
- Addition / deletion of extensions
- Addition / deletion of extension-points
- Addition / deletion of plugins
- Disablement use case
- Expected behaviour of the UI plugin in reaction to the enablement/disablement of any plugin
- Disablement of the UI plugin
- Expected behaviour of the Resources plugin in reaction to the enablement/disablement of any plugin
- Disablement of the Resources plugin
- Disablement of higher level plugin
- Disablement triggering
- Because the disablement disables functionnalities from the platform,
this operation must be done with care.
- API review
Other dynamic plug-in operations |
When the previous items will be done, we will be able to tackle those items very quickly since the basic
infrastructure will be in place.
- Partial activation of plugins
- Partially activation of the plug-in when only subset of it are required for simple operations (See primed state).
- Dynamic installation of a plug-in
- Install the plug-in from disk
- Give the plug-in an opportunity to run a onetime setup code
- Implication on the PlatformConfiguration -- Mel
-
Dynamic uninstallation of a plug-in
- Delete the plug-in from disk
- Give the plug-in an opportunity to do some cleanup
- Implication on the PlatformConfiguration -- Mel
- Plugin metadata handling (should they be automatically deleted, or should the user have hooks to do that?)
-
Update of a plug-in
-
Plugin disablement
- The plugin is unloaded for more than a session
- Tool requirements for such a support