Review/rework config API
Much has been done. The outstanding work appears to be:
#456 config: sort out default config file location etc.
#457 Default config file testing, and comment out settings
#458 Review config taxonomy
We should adopt a coherent and fairly transparent config management system in both
arti. Properties that I would like to see:
arti_clientcontains a config file reader and there is a convenient way to use it with its defaults.
- The config is sufficient transparent that an application can "pass thorugh" Tor-related config from its own configuration scheme without having to write code which knows about individual sections and values.
arti's config is done by extending
arti_client's config in this way.
- However, individual config settings can be set using native Rust types.
I think this means that at the very least
arti_client::TorClientCfg needs to be constructable from something which is
Deserialize. And it needs to have a simple enough data model that it is comprehensibly and readily expressible in at least TOML and JSON.
We should investigate at least the crates
configparser and perhaps others, and/or consider DIY
See also #284 (closed) in which I argue that the distinction between
TorClient should not be exposed.