[tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

[grarpamp]

On namespaces...

Like MIBs, APIs, file systems, most anything, it's usually...
least specific left to most specific right
... DNS also maintains hier but in reverse direction.


add_foo_thing1
add_thing1
add_thing2
see_bar_thing1
string_assorted_junk_this
...

gives you hierarchies of *add* filled with
all sorts of random things, doesn't sort,
and leads to documentation being scattered
as well, with assorted junk everywhere.


ONION_CLIENT_AUTH_ADD

is most clear... ONION (ok, what about onion),
CLIENT (ok, what about client), AUTH (ok, and...)
ADD (aha yes do that). And docs are self
ordering into nice sections.


ONION_CLIENT_ADD_AUTH

doesn't follow because it reverses the
last two thus breaking things again.


"We can't change"

Sometimes these positions can hold you back, allow
random in new things, expend mantenance on old chaos, etc.
If project codebases have a lot of legacy chaos, downstream
can appreciate and support refactoring in major releases,
even if they have to do a little work themselves to get that.
Announced mapping of legacy command support for removal
in next major releases can help there too.