Re: [Openrocket-devel] Plugin framework

[Sampo N. <sam...@ik...>]

Hi,

Good points there Richard...

On Sun, Jan 27, 2013 at 6:31 AM, Richard Graham <ri...@rd...> wrote:
> Configuration --- the interface should provide a standard way to
> configure 'global' options for the plugins and enable/disable them. I am
> thinking a simple plugins menu item which might look something like:
>
> Plugins
> Airstart
>  -> [x] Enable
> Elevation
>  -> [x] Enable
>  -> Configure
> Find new plugins ...  (opens website)
>
> Note that in the example of simulation extensions, this configuration is
> different from the 'per simulation' configuration which should also be
> available.

I hadn't thought of global configuration...  It may be a bit
problematic for the transferability of ork files.  Essentially I was
thinking that all simulation extension configuration would be written
to the ork files.  Having global configuration options may make the
files less portable.

Do you have some specific examples on what would be in global configuration?


I was also not planning on having any enabling/disabling functionality
for plugins.  Any plugin on the classpath will be loaded.  Is there
some need for such functionality?


> I do think that we really should be able to support extensions in
> android but I don't know of any good solution for not depending on
> swing. It may be that we would need to have separate versions of plugins
> for android.

I've been thinking of two alternatives, neither of which seems totally ideal:

1.  The Swing configuration is a separate plugin that is searched for
separately to configure the other plugin.  Essentially we'd be going
through all SimulationExtensionConfigurators and asking whether you
know how to configure com.example.MySimulationExtension.  (If a
configurator could not be found, then the plugin doesn't support GUI
configuration.)

2.  Some sort of indirection in the reference to the Swing portion.
The JRE loads classes late, so I believe classes in use can contain
code that utilizes classes that are missing (or utilize some class
that utilizes a class that is missing), as long as that code is not
called.  Alternatively (or together) it might help to have "Object
getSwingConfigurator()" which is then cast at runtime.  I don't know
enough of the class loading to be sure of these though.


Option #1 would clearly separate the UI code, while #2 might allow a
bit simpler code.  After a bit of though I think #1 is the way to go,
though I'm unsure how the searching should be performed.


> Datatypes --- we should make sure that plugins can reserve their own
> flight data types (which would then be available from
> doc.getFlightDataTypes()). Making sure that there are no conflicts would
> require that plugins are fully loaded before any files are loaded, which
> in turn means a restart is probably required after enabling a plugin. I
> guess that is ok.

Do they need to reserve them?  My idea has been that the data types
are dynamic, and more can be created on the fly as needed.  We would
just need to specify properly the equals() method, i.e. what two types
are considered the same and what are different.


> ORK file -- it seems it should be simple enough to provide something
> like a <plugin name="..."> tag in the file, the context of which would
> be handed off to the appropriate plugin if available. Likewise for
> simulation extension configuration. Each plugin would just need to
> provide a name and version info.

Exactly the "would be handed off" part I'm dubious about.  How do we
make a clean interface for reading/writing the configuration?

One option would be to create some kind of XML parsing methods in a
fashion that cannot break the XML output.  Another would be to limit
plugin configuration to key-value pairs which would be handled by the
load/save code.

I think it would be good to have some abstraction for a plugin
configuration which could be fetched and set for a specific plugin,
and stored/loaded in a generic way.  We might even use a custom
implementation of java.util.prefs.Preferences (though personally I
think that class is a mess..)?


-- 
   Sampo Niskanen   <=>   http://www.iki.fi/sampo.niskanen/