Discussion: command-line restructuring

[ianmcorvidae]

Creating an issue for discussion of this in general.

Right now, the CLI is built around merely a long list of options, which is making it difficult to document and maintain which options go together and don't and sometimes leading to unexpected behavior (e.g. until recently, traceroutes were always sent on the primary channel, even if --ch-index was included).

While I think we will need to maintain support for the existing options for a while, it would be much better if we could create subcommands (and sub-subcommands, etc.) that more carefully split up the different things the CLI is able to do and including only arguments and options that make sense. This would also ensure the CLI is much more self-documenting, as opposed to the current --help output that mostly provides a very long list of things that only potentially work together. With such a system in place, the pre-existing options can also be reimplemented in terms of the more structured interface, which can in turn help in their ability to be automatically validated.

We should put together a fairly comprehensive plan for how we want the CLI to look. One inspiration might be the C# command line which already uses a structure somewhat like this: https://github.com/meshtastic/c-sharp

As I see it right now, the biggest overall categories are:

• commands that read day-to-day information from the node without sending anything to the mesh, such as --nodes, --info, --device-metadata, and (somewhat) --listen, perhaps under something like an info subcommand
• commands that involve administering nodes (both getting and setting), such as --configure, --export-config, --set, --get, --ch-set, --ch-add, --reboot, --shutdown, --factory-reset, --setlat/lon/alt, --pos-fields, --ch-longslow/etc., --seturl, --qr, --get-canned-message and --set-canned-message, and many more -- this is a lot of what the CLI is used for, but I think may still belong under an admin subcommand (with more subcommands below that, for certain)
• commands that send or request things from the mesh, aside from administrative tasks, such as --sendtext, --traceroute, --request-telemetry, and --request-position. I'm not sure these all belong under the same subcommand; we might have a few like send and request with their own subcommands and shared implementation details (given that requests and traceroutes are, of course, also messages sent to the mesh)

As always, I don't claim any sort of special knowledge or insight here. I'd like to hear what others think so we can make the most comprehensible base we can. I'd also love to hear if there's features that others would like to see added. One that I've been working on somewhat is implementing a client proxy for MQTT.

Another thing we may at some point want to handle is that nodes only support a single connected client, so it could become valuable to implement some sort of "server mode" that maintains a single connection to a node but allows CLI commands to be directed at the server process. Luckily, that would probably just be its own subcommand in this structure, with a paired connection argument to connect to a server process.

Previously: #566