Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Arti Arti
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 147
    • Issues 147
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • ArtiArti
  • Issues
  • #285

Closed
Open
Created Jan 12, 2022 by Ian Jackson@DizietMaintainer0 of 3 tasks completed0/3 tasks

Review/rework config API

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.

Edited May 09, 2022 by Ian Jackson
Assignee
Assign to
Time tracking