pikers/piker

Exposing subsystem functionality controls in `conf.toml`

Opened this issue ยท 0 comments

Obviously related to both #529 and #221 we have a TON of stuff in many sub-systems that can be exposed for manual user control ๐Ÿ˜‚

The latest example of this is from #523 which more or less allows user tweaking of the "scaling" of all widgets in our UIs by setting a font size..


Where to start

  • search for todo notes in the code base with:

    • git grep config.toml
    • git grep conf.toml
  • more or less off the top of my head (lul):

    • .data.feed. throttling controls (search for tick_throttle)
    • data.flows.Flume memory allocation size depending on OHLC sample rate
    • .service related (actor) daemon socket-address settings, maybe registry definitions?
      • for eg. defining the network transport layer addresses over multiple hosts ๐Ÿ˜Ž
    • .accounting._allocate settings for order sizing and limits
      • (maybe on a per asset type basis?)

Testing

  • add at least one validation test that ensures the minimal set
    of fields are present in the conf.toml file
  • ideally per subsystem functionality tests of some sort:
    • setting .data.feed throttle rate results in measurably
      limited tick rates.
    • set .data.history related ShmArray (buffer) mem size
      and make sure /dev/shm files are sized to match.