Ticket #1451 (closed task: moved)
Opened 2012-08-30T14:02:17-05:00
Last modified 2014-07-18T13:41:33-05:00
Consolidate options, prefs and config logic
| Reported by: | curtis | Owned by: | curtis |
|---|---|---|---|
| Priority: | minor | Milestone: | imagej-2.0.0 |
| Component: | Core | Version: | |
| Severity: | non-issue | Keywords: | |
| Cc: | Blocked By: | #1706 | |
| Blocking: | #1400 |
Description
Currently, we have a package imagej.options with an OptionsService, as well as a separate imagej.config package with a ConfigFileParameters class for working with the ImageJ.cfg launcher file. We also have imagej.util.Prefs for managing persistence of key/value string pairs.
We should strongly consider consolidation of all these, eliminating any redundant concepts.
Change History
comment:24 Changed 2013-03-21T13:38:34-05:00 by curtis
- Blocked By 1706 added
(In #1706) Firstly, note that the preferences are loaded and saved as part of the preprocessing chain during command execution. The relevant preprocessors are:
And the actual saving and loading code for module items is unfortunately hardcoded right now.
From my perspective, it is clear from your comments that this logic should be refactored into its own service class as part of the ticket #1451 work. That way, any future deficiencies in the persistence mechanism could be fixed downstream by using an alternate service implementation.
When an application launches, if it does not find a node for itself, it could optionally copy or translate the values from an old version node
Yes, it would need to copy the values from the next level up the tree. And when persisting the values, it would need to store them to its node, as well as higher level nodes ("stomping on" the previous values) for the benefit of future contexts. This scheme would allow concurrent contexts to keep separate track of preferences, avoiding some concurrency issues at the expense of increased complexity. (E.g., some people might be surprised or confused when different contexts retrieve different persisted values from what they might assume would be a common storage mechanism.)
Another concern I have is what to use for the context identifiers. If we use positive increasing ID numbers, when a context first starts up in a fresh JVM it might inherit the persisted values from the previous JVM's context(s), assuming we start again from "1" each time. Or we could persist the last-used context ID, and have an always-incrementing long, which would ensure each context has a nearly-eternally-unique ID, but then the persisted preferences would become major cruft over time. Alternately, rather than using the Preferences API for context-specific preferences, we could store them in a data structure of the service rather than on disk via the Preferences API, which would be my tentative preference.
Thoughts?
comment:25 Changed 2014-07-18T13:41:33-05:00 by hinerm
- Status changed from new to closed
- Resolution set to moved
Moved to github: https://github.com/imagej/imagej/issues/95