Hello Juan,

thanks for bringing up this topic, this is something I think we should
address in one form or another.

On Mon, Sep 09, 2019 at 03:46:13PM +0200, Juan Ignacio Carrano wrote:
> 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.

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to