-
Couldn't load subscription status.
- Fork 6
Description
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
-cor--configfor cloud deployment - Not mandatory, (re)created with defaults when it does not exist upon launching, so no setup required to "just start" the app