Avoiding Random Constants Everywhere. Configurable ROV

[cal-pratt]

Right now we have a lot of statically defined constants for our various classes. We also have three other ways that we get configuration properties. There's the org.apache.commons.cli Option.builder that we see in the main methods, the java.lang System.getProperty we see throughout the code, and there's java.util.prefs Preferences for persistent data... Gross. mucho dislike.

I asked a question here about configuration and got a reasonable response. The suggestion was to do away with all these different methods and use a single concept for configuration. And also to make absolutely all static constants configurable (apart from values in test code; this is for main application code only)

What libs do we use?
I've been looking up some libraries, and it seems that Commons Configuration Library could be a good choice.

How do we synchronize configs across all devices?
I think we could make a script, similar to the shutdown/ restart scripts, that logs into each device, updates the config file, and restarts the control software. This way we only need to edit the file on topsides and then push it to the Rasprime/ PiCameras.

How do we use a config to save objects?
It wouldn't be too hard to write a wrapper around the commons-configuration lib that turned objects into json and put them into a .properties file. We could then do away with the ResetGUI program and just remove lines from our .properties

public <T> T readConfig(String lookup, Class<T> clazz) {
    return mapper.readValue(config.getString(lookup), clazz));
}
public <T> void writeConfig(String lookup, T t) {
    String json = mapper.writeValueAsString(t);
    // Some way to edit `.properties` file

Do we keep default values and make configuration optional?
If yes do we continue to try and make defaults up to date? Seems counter-intuitive..
If yes should we only keep default values to allow tests to pass?
If no do we create a separate configuration file for tests?

Where do we store configuration files?
We can keep the most updated one on github. The user can then edit a file which overwrites values in this default config.

Should we allow for multiple configuration files?
If so we need to know how to load one specifically without modifying the other; and worry about applying critical configs (like motor/ thruster addresses) to everyones config. Would probably be better to avoid this for a version one.

[ConnorWhalen]

I'm thinking having defaults could make things more complicated like you're saying. It turns into managing two separate config files, your config and the default. Maybe we can do without the defaults for version 1.0 or even version 0.1 and assess if there's a case for it.

This looks like it could be a big win though