Skip to content

Self-documenting & simplified config yaml #388

@Cafe137

Description

@Cafe137

Configuration

Considerations:

  • Needs object and comment support (IMO yaml)
  • Make it very obvious what is enabled and disabled (explicit enabled: true, not a mix of env vars magically turning something on)
  • Self documenting: structured objects, descriptive names, helpful comments that explain the use case
  • Avoid reusing the same variable in multiple features
  • Defaults are visible
  • All features are laid out, no README.md digging

Refactoring

Separate stamp management features. Currently auto-topup and auto-dilute both purchase stamps. In code, implement strategy pattern to clean up and separate concerns. I don't think mutually exclusive features should exist, nor should a feature do partially what the other feature does.

New features

Ceilings

Some situations should require user interaction, e.g. when a stamp grows in depth too much, or if an operation is too costly. E.g. the example config of stamp.global.maxCost: 1 BZZ

Selective or inclusive stamp management

Currently we only consider stamps valid if they match the configured amount and depth. IMO we should extend it to either allow all, or mark stamps with the label property, and manage those in all modes.

Units in config

e.g. 10s, 2m, 80%, 1BZZ

Test configuration

e.g. gateway-proxy -t (nginx) should validate and print in a human friendly way what the configuration is

Deploy configuration on first run

  • Have a default path for it
  • Can be specified by -c or --config for cloud deployment
  • Not mandatory, (re)created with defaults when it does not exist upon launching, so no setup required to "just start" the app

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationenhancementNew feature or requestissue

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions