Scoreboard assumes that its install location is writeable

[davidmreed]

Context: I am interested in working on new distribution strategies for the Scoreboard, such as Linux (Debian/NixOS) packaging, Docker images, live USB sticks, and standalone distributions that don't require a JRE. My goal is to create artifacts that simplify initial setup and maintenance of league-owned scoreboard machines.

--

The Scoreboard relies in a number of places on the assumption that the directory where the application's resources are installed is writeable. For example, JSON stats files are written by the server into the html/game-data directory, and resources uploaded by the user are stored in the same directory tree as the Scoreboard's default resources.

This assumption makes packaging and distribution difficult for a few reasons:

1. Because there is no separation between user content and application defaults, it's challenging to define a packaging structure for the out-of-the-box content.
2. It is tricky to create a structure where the scoreboard application can be maintained (or restored to) a pristine state, while preserving user-owned data.
3. The locations where packaged binaries are installed on many Linuxes are not user-writeable.

I'd like to work on solving this. My initial stab at a solution is to make two changes:

1. Add a class ConfigPath parallel to BasePath. Default it to "." to preserve the current behavior, and allow it to be set via a command-line option.
2. Direct all filesystem operations that expect write access to ConfigPath instead of BasePath.
3. Wherever resources are read that may be customized by the user (such as in JettyServletScoreBoardController), try reading from ConfigPath first, and then fall back to BasePath if not found. The end result would be that any user-customized or -generated data is preferred, then out-of-the-box resources.

Would y'all be open to a PR implementing this strategy?

[frank-weinberg]

I see the problem and the strategy sounds reasonable.

I'm not sure if I'd include that in a 2023. release or push it back to 2025. (due for the new WFTDA season mid 2024) - while it should not affect users unless they explicitly set a non-default ConfigPath, there might be quite a few pieces of code affected, introducing a certain risk of new bugs.

[frank-weinberg]

@davidmreed Are you still pursuing this?

[davidmreed]

@frank-weinberg Yes, although I've not been focused on it lately - I wrote the code but need to do some hands-on testing with upload/download flows to make sure it doesn't impact them negatively. I'll try to pick it back up shortly.

[frank-weinberg]

No worries, I mostly wanted to keep the status of the ticket up-to-date. Though given that we are currently in beta, it is a good time to bring in non-trivial-features.