[tor-bugs] #30984 [Core Tor/Tor]: Make a key-value line abstraction to output control replies

[Tor Bug Tracker & Wiki]

#30984: Make a key-value line abstraction to output control replies
--------------------------+------------------------------------
 Reporter:  catalyst      |          Owner:  catalyst
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:  #29210        |         Points:  5
 Reviewer:                |        Sponsor:  Sponsor31-can
--------------------------+------------------------------------

Comment (by catalyst):

 Replying to [comment:4 nickm]:
 > I'm not sure that wrapping config_line_t and putting the results in a
 smartlist_t is the route I would recommend here: config_line_t expects to
 be in a linked list.
 I was thinking that each smartlist element would be a length-one linked
 list of `config_line_t`, under most circumstances. Exceptions would be
 reply lines with multiple machine-parsable key-value elements, like many
 of the async event control replies. For these, it would be nice to use
 `kvline_encode()`.

 There are three main categories of reply lines that I see (ignoring the
 difference between a `MidReplyLine` and `EndReplyLine` for now -- part of
 the goal of this is to automatically figure out which to generate):
 * Entire line after the numeric code and separator is meant to be human
 readable, and not generally machine-parsed
 * Entire line after the numeric code and separator is a single `key=value`
 pair
 * Line is a `DataReplyLine`, followed by multi-line `CmdData`
 * After numeric code and separator, a list of machine-parsable keywords or
 `key=value` pairs. These are mostly async control events, but there are
 some synchronous replies that are like this, including `PROTOCOLINFO`.
 These are the reply formats that would benefit most from
 `kvline_encode()`.

 Or maybe I should start by making a new structure for control replies,
 starting with reply code numbers and flat strings? Then stuff that could
 benefit by building up `key=value` argument lists could still use
 `kvline_encode()` explicitly, at least at first. Some of the existing
 control replies like `GETINFO` and `GETCONF` don't quote things the way
 `kvline_encode()` would like to.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30984#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online