| Enable/disable approach [message #26103] |
Wed, 18 June 2003 03:42 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
This is primarily to Keith and Rafael may be of interest to others...
The dynamic plugins work has been happening but is not being reflected well
in the website. In looking over the dynamic plugin area on the web there is
a mishmash of information, approaches, issues, ... It would be great to
clean this up and make it reflect our current thinking, contain concrete API
specs etc. Also, lets flatten it a little bit. The current structure makes
it hard to find things.
Just to add some grist to the mill, below is a rough, point-form outline of
what Rafael and I have discussed over the past day or so. Much of this is
already captured in various parts of the current web. It would be great
combine.
Jeff
- enable/disable is just the lowest level install/configuration action which
can affect the registry
- the registry should reflect only the resolved plugins
- enabled but unresolved plugins can be discovered *somewhere*. I'm not
sure where *somewhere*. It may be ok on the registry but it seems a little
funny. Also, what do we want to report here. Just the id and version of
these unresolved plugins or the whole parsed state. We should seek to
reduce our workload and memory footprint. ==> as little info as possible
should be maintained. Note that the list of configured but disabled plugins
is available from the configuration and need not be reported by the
registry.
- resolution should support policies like "global vs. local optimization of
version selection", "perturb the system as little as possible", "just do
it", ...
- we must be able to discover the results of resolution before actually
affecting the system
- we must be able to explain resolution results. That is, the API user
should be able to discover that plugin X is unresolved because version 1.4
of Y was selected because, ...
- resolution results in a delta which captures transitions: resolved,
unresolved, changed (prereq selection changed, extension contributions
changed).
- the primary purpose of the delta is to capture changes in the set of
extensions and extension points and their interconnections.
- the delta should be broadcast to the set of "interested parties".
Interested parties are those plugins which are relevant in the context of
the given operation (e.g., if plugin A is newly resolved and contributes
extensions to plugin B, B is interested) and those listeners which are
explicitly registered to receive such events.
- listeners can quickly and cheaply discover if a delta contains anything of
interest to them.
- broadcasting the whole deltas gives listeners more context for the change
and allows for more effecient updating. Consider the UI plugin and its
action extension point. Plugins may contribute any number of action
extensions. E.g., each of 5 extensions would trigger a UI notification.
The processing of this notification may include recomputing menus and
perhaps even redrawing portions of the display. This may be costly and
distracting to the user. In contrast, if the UI is told of all 5 additions,
it can batch process them and update the menus, display, ... only once.
- The efficient handling bulk enable/disable of plugins is essential. The
whole update/install model is based on features (i.e., collections of
plugins).
|
|
|
Powered by
FUDForum. Page generated in 0.03436 seconds
] 
Search
Help
Register
Login
Home
