Skip to content

Exposing subsystem functionality controls in conf.toml #530

@goodboy

Description

@goodboy

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions