During the Summit 2019 @vincent-d mentioned the possibility of remotely executing shell commands and @HendrikVE had a working shell-over-bluettoth.
I just wanted to point out to you some work in that direction that may (or may not) be useful. With the PRs I mention below it should be easier to implement something like a CBOR/JSON based interface based on COAP or any other protocol.
The first one is PR #10624 by @MrKevinWeiss which tries to define a common output format for shell commands. In particular, it provides a consistent way of reporting the return code of commands. The tricky part here is that it is still text based.
The other is PR #9538 by me where I define some data structures to express the arguments to a command and also provide a parser. The parser is not important here, but the structures could allow arguments to be parsed from a document (e.g. JSON/CBOR/etc) and introspection by making the commands self-describing.
I’m not sure we should migrate the shell to a completely structured output. Though I can see the benefit of that wrt remote execution via CoAP/CBOR, a shell should be primarily human readable. However, maybe there is some middle ground to be found for that. Another interesting read with regards of input parsing might be this draft by Carsten: https://tools.ietf.org/html/draft-bormann-t2trg-slipmux-02.
thanks for bringing up this topic, this is something I think we should
address in one form or another.
I just wanted to point out to you some work in that direction that may (or
may not) be useful. With the PRs I mention below it should be easier to
implement something like a CBOR/JSON based interface based on COAP or any
other protocol.
CoAP and command line not only have different conventions (?foo=bar vs.
--foo bar, return codes) but also different properties (a CoAP request
can be safe or idempotent, a terminal command might be long-running and
cancellable).
I think it does make sense to create building blocks that can be
combined to create the same functionality on different interfaces, but
until we find the great unified theory of RPC and everything that's not
really RPC but similar, I'd rather have them combined case-by-case. In
such a scheme, the command-line and CoAP handler for the "ps" command
could be short glue code functions each that do some per-mechanism setup
and then call into a ps workhorse function that drives what has been set
up.
The optparse approach looks like it could be such a component, even
though I'm not sure it is suitable for idiomatic CoAP options in its
current form. Another component I envision we could have is some kind of
table formatter, where the command line output would be set up with a
format string (a la "| %-5d | %*10s | %*5d | %s"), and a CoAP renderer
would produce CBOR instead.
One consideration I'd appreciate being considered here is code size in
absence of the shell being built. I'd like my `ps` to be available on
small builds that can't afford a shell. If the mere possibility of using
it with a shell makes its implementation much larger, I'd rather go for
independent implementations of the command for the different control
channels.