Refactor our controller-command/torrc-option processing logic into a data-driven function
Throughout our controller protocol and our configuration code, we process things with more or less the following metaformat:
Line = PositionalOptions | KWDOptions | BothOptions
BothOptions = PositionalOptions SP KWDOptions
PositionalOptions = PosOption | PosOption SP PositionalOptions
KWDOptions = KWDOption | KWDOption SP KWDOptions
PosOption = QuotedOption | NonSpace
QuotedOption = QString
NonSpace = PChar*
KWDOption = KWDName "=" PosOption
PChar = a printing, nonspace character.
QString = DOUBLE_QUOTE QContent* DOUBLE_QUOTE
SP = One or more whitespace characters
We should have one generic function that parses a config line or command into a list of positional and keyword arguments, and another that takes such a list, typechecks it, and converts it into a structure (in the same way that config_assign does). The latter function could even be config_assign.
In theory, this should make our parsing more convenient, and remove a bunch of duplicate code.
(Did I already open a ticket for this? I'm not seeing it if so.)
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information