GitLab

Current tickets

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

Previous summary

IMO:

We should adopt a coherent and fairly transparent config management system in both arti_client and arti. Properties that I would like to see:

• arti_client contains 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 config figment configparser and perhaps others, and/or consider DIY serde impl.

See also #284 (closed) in which I argue that the distinction between TorClientConfigBuilder and TorClient should not be exposed.