| [reply] |
Because it's a centralized repository, and having it in the registry allows much easier management when upgrading.
It's also a lot less taxing (code and process time) doing quick registry reads than it is opening, reading, parsing, converting from and closing a JSON file on each run in C#.
It also ensures the configuration is always in a single, specific location, so it can be read and modified without having to figure out where the installation is located (by parsing and then searching each PATH for the berrybrew.exe binary, then loading the file from the data directory).
Makes testing a whole lot easier as well.
You can still utilize the config file if you please:
- Modify a configuration file variable
- Run berrybrew options-update-force hidden command to reload all options from the file
It still utilizes the registry though, but the process without using the hidden command to force reload the options, the config file is read only once... upon first run of the software.
The main reason that made me change my mind from file to registry is that in this version, registry work was required for other features... UI at startup, installer/uninstaller data storage, and the modification of the .pl file association work. Once the registry became involved, migrating the config over was a natural progression.
The next version is dedicated 100% to drastically increase test coverage. No new features will be added, unless they are a side-effect of finding something while adding these new tests. I plan on adding a minimum 10x the number of tests I have now. This will allow me to find a lot of areas where I can make the code a whole lot better and more efficient, and provide better scoping for error handling. Getting the registry stuff implemented in this most recent version allows all of the new testing to be future proof.
| [reply]
[d/l]
[select] |
I see
It's also a lot less taxing (code and process time) doing quick registry reads than it is opening, reading, parsing, converting from and closing a JSON file on each run in C#.
Makes testing a whole lot easier as well.
Hmm, doubtful
It also ensures the configuration is always in a single, specific location, so it can be read and modified without having to figure out where the installation is located (by parsing and then searching each PATH for the berrybrew.exe binary, then loading the file from the data directory). $HOME/.berrybrew is just as specific and doesn't require much figuring out
| [reply] |
