plugin settings cross-contaminate across documents.

[timobaumann]

I wonder how to fully resolve the underlying issue in #165 : some plugins keep states (the synthesis plugin has a default speaking tempo, LEGO has devices, SQL has its database) and loading a second document from file later will overwrite the values for all other documents. (I tried this with SQL but would think the same happens for LEGO; synthesis simply forgets its assigned tempo.) It's less concerning that we overwrite what's in memory (i.e., no two ducuments open at the same time that require access to different SQL databases), but it's annoying that they would even overwrite each other's contents if saved. @alexanderkoller: do you think your plugins suffer the same problem and do you have any good/simple+easy-to-implement idea of how to avoid it?

[alexanderkoller]

Oooh, if that's accurate, that would be an absolutely terrible design flaw in DialogOS which we should fix asap.

At first glance, I don't quite understand how this could happen. PluginSettings objects are created in the constructor of com.clt.diamant.SingleDocument; thus, as far as I can tell, each document should have its own instance of the settings of each plugin. Do some plugins - or the code that reads and writes plugins to the XML file - use static variables that are shared across instances of PluginSettings? Or does the Properties mechanism introduce some weirdness?

Can you provide a minimal example (with an existing or a new toy plugin) that illustrates this cross-pollution? I'm probably best positioned to look into this right now, and would be happy to.

[timobaumann]

There's an Interface com.clt.dialogos.plugin.PluginRuntime which may have been part of the solution in the past:

• the interface does not do anything except having the ability of being disposed off.
• the ASR&TTS plugins just return null when asked to createRuntime()
• having a runtime doesn't make a difference anyway, because PluginSettings#getRuntime() is only called by Node#getPluginRuntime(). and that's never called by anything. Maybe that's the problem.

git log tells me that (the current repo) used to contain references to getPluginRuntime() but those seem to have gone away since. @alexanderkoller, can you take a look at older sources and check if you find out what these runtimes were meant to be and how they were meant to be used?

[alexanderkoller]

As far as I can tell, a PluginRuntime is created for each execution of a graph (i.e. too short-lived to be useful here). It is used e.g. in the NXT plugin to hold the connection to the Lego brick.

Subclasses of Node can get access to their PluginRuntime object during execution via Node#getPluginRuntime.

As I said above, the Settings object should have the correct lifespan right now: one instance for each SingleDocument object. Could you give me a minimal example that illustrates the cross-pollution of Settings objects? I'd be happy to look into it.

[timobaumann]

Can you provide a minimal example (with an existing or a new toy plugin) that illustrates this cross-pollution? I'm probably best positioned to look into this right now, and would be happy to.

See 12.zip:

• Open 1.dos (which contains a spelling for 1),
• open 2.dos (which contains only a spelling for 2),
• move around a node in 2.dos so that it can be saved,
• save 2.dos find that 2.dos now contains spellings for both 1 and 2.

I know that the SphinxPlugin is really not a good candidate for a minimal example but that's all I got for now.

[alexanderkoller]

Thank you! I will look into it later this week.

[timobaumann]

this doesn't seem to be a principled problem with the architecture but only with some fauly plugin implementations. I've fixed SQLite, Sphinx is still broken. MaryTTS and ROS weren't affected.