Hi Pau,
On Wed, Feb 17, 2021 at 10:30:25PM +0100, Pau Espin Pedrol wrote:
SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3 or SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3
I'd probably go for this one from all the ones you proposed. This way, you keep the usual CTRL structure ("." separating/slitting parameters), while you simply add a new character to specify "levels" or "nodes" (as per VTY terminology).
ACK.
The question here is how to define information in code to apply getter/setters for CTRL commands...
Not sure I'm following you here?
Somebody may not like the idea, (and may be not directly related to the topic at hand), but perhaps looking at something similar to a REST interface which provides json output and which can easily be interacted using python or even curl directly. REST interface provides already way to provide levels/nodes (URL directories)as well as parameters "?foo=bar&hello=bye"). So using HTTP may not be needed, but it may make sense to reuse some REST related ideas, like URLs and json output (with C implementation in 1 file like cjson).
CTRL started with the idea that somebody wants to perform basic SNMP style SET/GET/TRAP operations, but we didn't want to import the complexity of "Simple" SNMP parsing/encoding/... in a non-blocking fashion. It was never intended to do anything else but setting or getting a single value in each command, and sending the occasional TRAP.
I do think whatever we do as a next iteration (if any) should center around that external MIB / configuration store idea. At that point the osmo-* program becomes a client to the config store, ideally with transaction/commit/rollback logic, and anyone can come up with whatever interface they want towards that config store - if it's not already a well-documented and established interface to begin with.