Ticket #1451 (closed task: moved)

Opened 7 years ago

Last modified 5 years ago

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:1 Changed 7 years ago by bdezonia

  • Blocked By 490 added

comment:2 Changed 7 years ago by bdezonia

  • Blocked By 564 added

comment:3 Changed 7 years ago by bdezonia

  • Blocked By 612 added

comment:4 Changed 7 years ago by bdezonia

  • Blocked By 790 added

comment:5 Changed 7 years ago by bdezonia

  • Blocked By 903 added

comment:6 Changed 7 years ago by bdezonia

  • Blocked By 904 added

comment:7 Changed 7 years ago by bdezonia

  • Blocked By 960 added

comment:8 Changed 7 years ago by bdezonia

  • Blocked By 962 added

comment:9 Changed 7 years ago by bdezonia

  • Blocked By 980 added

comment:10 Changed 7 years ago by bdezonia

  • Blocked By 982 added

comment:11 Changed 7 years ago by bdezonia

  • Blocked By 1266 added

comment:12 Changed 7 years ago by bdezonia

  • Blocked By 490 removed

comment:13 Changed 7 years ago by bdezonia

  • Blocked By 564 removed

comment:14 Changed 7 years ago by bdezonia

  • Blocked By 612 removed

comment:15 Changed 7 years ago by bdezonia

  • Blocked By 790 removed

comment:16 Changed 7 years ago by bdezonia

  • Blocked By 903 removed

comment:17 Changed 7 years ago by bdezonia

  • Blocked By 904 removed

comment:18 Changed 7 years ago by bdezonia

  • Blocked By 960 removed

comment:19 Changed 7 years ago by bdezonia

  • Blocked By 962 removed

comment:20 Changed 7 years ago by bdezonia

  • Blocked By 980 removed

comment:21 Changed 7 years ago by bdezonia

  • Blocked By 982 removed

comment:22 Changed 7 years ago by bdezonia

  • Blocked By 1266 removed

comment:23 Changed 6 years ago by bdezonia

  • Blocking 1400 added

comment:24 Changed 6 years ago 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 5 years ago by hinerm

  • Status changed from new to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.