[ImageJ-devel] Regarding Preferences support for Multiple Instances, Applications, and Versions

[Grant B. Harris]

ImageJ2ers,

We've recently run into the problem of having multiple versions of 
MicroManager installed (for testing our plugins under different 
versions).  This made me realize that there are some issues with ImageJ2 
preferences that we may want to address.

Right now, Prefs are stored in the userRoot() by Class<?> and name.

I don't think that this allows us to support any of these scenarios:
- multiple applications (that use the application framework)
- multiple versions of the same application
- multiple instances (contexts) of the same application

I all of these cases, they will stomp on each other by reading/writing 
the same Prefs.


I'd like to propose an extension to the Prefs mechanism which follows:

When an application launches, if it does not find a node for itself 
(applicationA/v2.0), it could optionally copy or translate the values 
from an old version node (applicationA/v2.0).  The Prefs class could 
provide some helper methods for this.  The Prefs nodes could be 
something like this:

userRoot()
     /applicationA
         /v1.01
             /...
         /v1.02
             /...
      /applicationB
         /v2.0
             /...

To deal with multiple instances (contexts) of the same application, it 
might make sense to have the prefs stored by context (perhaps under a 
node for application and a node for each version.  It seems that each 
instance would need to have an identifier, and this identifier would 
need to be set when the app. (re-)launches, perhaps using a command line 
argument.

While less common, the ability to have multiple instances (contexts) of 
the same application can be useful in two use cases I can think of: 1) 
running instances running headless on a server, 2) having multiple users 
of an application on the same OS user account (like 'guest').  A context 
identifier would also enable separate prefs settings for these situations.

Using context identifiers, perhaps the Prefs nodes could be something 
like this:

userRoot()
     /applicationA
         /v1.01
             /...
             /cID1
                 /...
         /v1.02
             /...
      /applicationB
         /v2.0
             /cID1
                 /...
             /cID2
                 /...

For example, if a context identifier is provided, the app. would use the 
nodes under /applicationA/v1.01/cID1... and if a context identifier is 
not provided, the app. would use the nodes under /applicationA/v1.01/...

Perhaps Prefs could be Contextual, and then use getTitle(), getVersion().
(For the context, I suppose one kluge would be to add something to the 
Title...)

There may be some related issues, e.g. in ConfigFileParameters, this is 
hardcoded: CONFIG_FILE = "ImageJ.cfg";

Thoughts?  Ideas?

(I've added this as an issue ticket in TRAC.)

-- Grant