#1 Specify algorithm parameters using extension points
- 1 Summary: The current method of specifying algorithm
parameters in
code is not sustainable in the long run.
- 2 Reasons:
- 2.1 Duplication: The current model violates the DRY principle.
The
same boilerplate code is repeated over and over. Changing
the
interfaces of the algorithms, etc will require changing all the
plugins. It may or may not be possible to migrate plugins
from
the older to the newer framework in a simple manner. We
need to
ensure at any point that the framework does not involve
manual
editing of configuration files or writing 'migration scripts'.
Such an architecture is going to be a recipe for disaster.
- 2.2 Inextensible: Its very hard to build other (user) interfaces
on
top of this framework because they all would have to
communicate
through Java.
- 2.3 Unusable: Its not human-readable or editable. One of our
main
goals is to ensure that whatever we create should be simple
enough that normal people can understand and manipulate it
without resorting to reams of documentation.
- 2.4 Non-OSGi-Compliant: The current way in which we
operate plugins
does not make them fully OSGi compliant. As a result,
making
these plugins deployable over the network will require a little
more work than what we would have needed to do if they had
been
fully compliant.
- 2.5 Not Scaleable: Forces early startup! This means that we
have
essentially taken out the main scaleability management
mechanism
out of the equation. Making all algorithms, etc to be started
up
early means that *we are not taking advantage of the
scaleable
nature of the Eclipse platform*.
- 3 Advantages:
- 3.1 Extensible: The parameters are specified as an extension
point
meaning that anything that needs parameters can use this.
- 3.2 Parsable: XML can be parsed and manipulated to do
many things
such as automatically generate documentation, build
programming
stubs for other libraries, etc.
- 3.3 Evolving: XML does not have to be limited to just the
parameters. We can add more metadata to this manifest in
the
future if needed *without* modifying any of the interfaces.
The
only thing that will need to be added (hopefully!) will be an
extension point processing class for each extension point.
- 3.4 Scaleable: Avoids early startup in most cases. Pushing
compatibility check into plugin.xml means that the extension
point processing code can, at processing time, create the
menu-items and set them to be enabled/disabled at
initialization
without calling the plugin's supports() method. I say 'most
cases' because to maintain full flexibility we will need to
provide a way for plugins to do runtime-compatibility
checking.
See later on in this document for that.
- 3.5 Usable: Template code can spew out XML instead of
writing out
Java code. Developers can use Eclipse's built-in plugin
manifest
editor to modify their extensions instead of resorting to Java
code. That is a big plus for usability.
- 4 Disadvantages:
- 4.1 Loss of compile-time type checking. With Java5.0, it is
possible
to make property maps use parameterized keys and values
and
therefore provide compile-time type checking. We will lose
this
if we move to plugin.xml. In fact, developers will know of
problems with spelling, etc only when either 1. the
extension-point processing code parses it and/or 2. the plugin
is started up. Given how Eclipse works, this will normally
cause
the plugin to be *silently disabled*. The current core only
performs runtime-type checking on parameter maps using
instanceof checks (nasty, in my opinion) so I don't think its
getting worse than it already is.
