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

[Curtis Rueden]

Hi Grant,

Thanks for bringing up this issue. I have added a comment to the
corresponding Trac ticket:

    http://trac.imagej.net/ticket/1706

Regards,
Curtis


On Tue, Mar 19, 2013 at 4:13 PM, Grant B. Harris <gharris at mbl.edu> wrote:

> 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
>
>
> ______________________________**_________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/**listinfo/imagej-devel<http://imagej.net/mailman/listinfo/imagej-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130321/b81c5852/attachment.html>