Re: [Openrocket-devel] Plugin framework

[Richard G. <ri...@rd...>]

Hi Sampo,

Quite a few things here.

Some examples that come to mind for 'global' configuration are: address
of server to use for getting elevation / weather data, location for
cache files etc. Also configuration for plugins that work on the whole
rocket document -- for (a bad) example say a plugin that goes through
and changes the colour of each component in the rocket or something like
that.

There are actually two things that 'global' configuration could mean,
either relative to the rocket document or relative to all documents. I
think both of these are required. I think the simplest way for this to
work is to store configurations in a tag in the .ork file as I
described. Also there should be a 'save as default' checkbox in the
configuration for each plugin. If checked the configuration would also
be saved via the preferences system (may need some re-engineering). This
configuration would be applied automatically when the plugin loads.

I don't think there is any big problem in terms of file portability, you
just ignore the configurations for any plugins that can't be found. This
is already backwards compatible to some extent as OR already ignores
random stuff in the XML and gives a warning.

I do think ideally we should have a better way to enable/disable plugins
than just moving the plugin jar file. Every other program I can think of
that has plugins has this ability. Suppose a plugin is messing up OR in
some way, you want to be able to easily disable it for troubleshooting.
On that note, I would also recommend a 'safe mode' command line flag
which opens OR with all plugins disabled.

Regarding the handing off of xml data to the plugin: from the
perspective of writing a plugin, the nicest thing would be to pass
in/out a DOM (or similar) object representing the <plugin> XML fragment
and do what you want with that. I know it doesn't mesh well with the
rest of OR which uses a SAX parser. You could also just pass a string of
the whole fragment and let the plugin writer figure out what to do with it.

Regarding the swing dependency problem: this is really an annoying
problem with java. In dynamic languages you basically get your #2
solution for free. It seems like there must be some way to do this in
java but I don't know how to code it.

If you do prefer your solution #1, I would suggest an alternative more
general way to write what you have described. Essentially what is needed
for plugins to have a list of dependencies which are automatically
loaded if they have not been already. This is potentially a useful thing
to have, independent of solving this particular problem. So you would
have something like:
 myplugin-pc.jar : contains the platform specific stuff and depends on;
 myplugin.jar : which contains everything else
You could just use something as simple as a name suffix as above to
avoid loading the plugins from the wrong platform. To avoid the user
having to copy both files you could use the jar-in-jar code we already have.

Regarding the flight data types: I do like the datatypes system, but
there are some unintended consequences of them being created on the fly
which I came across when working on the custom expressions. I think
these are all easily enough solved as long as plugins can define the
datatypes they use. Much of the work has already been done.

One example: the usual way to do a simulation is to set your simulation
options *and* the variables you want to plot, then run the simulation
and the plot pops up. But if the simulation has not been run yet then
the datatype system will not know about the types generated by
simulation listeners and these will not be available in the list of
variables to plot.

Also, there are various conflicts that could occur which should be taken
into account. Someone could define a custom expression with a particular
name or symbol then load a plugin which produces data with the same type.

Good luck,

--
Richard


On 01/27/2013 01:46 AM, Sampo Niskanen wrote:
> 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..)?
> 
>