Re: RFC: generic CTRL interface for VTY config settings

On Tue, Feb 16, 2021 at 04:23:12PM +0100, Harald Welte wrote: We also have numerous commands where there are spaces that would look weird when written as e.g. # or @: network handover1 power budget hysteresis (<0-999>|default) We have commands where the values are interleaved with keyword tokens, i.e. where there is no clean name -> value relation: neighbor lac <0-65535> arfcn <0-1023> bsic (<0-63>|any) We have commands that are additive: si2quater neighbor-list add earfcn <0-65535> thresh-hi <0-31> thresh-lo <0-32> prio <0-8> qrxlv <0-32> meas <0-8> si2quater neighbor-list del earfcn <0-65535> Commands without a value part: allow-attach no periodic location update Trying to translate all of these cases into CTRL-like name->value feels very hacky to me, with many quirks and pitfalls waiting on us around numerous corners. We'll run into ambiguities, escaping issues, and unreadable commands. A cleaner approach seems to me to have a CTRL command that invokes VTY lines, with a defined line separator, with VTY commands as-is in the "value" part of the CTRL command. E.g.: SET config network;bts 0;trx 1;timeslot 0;training_sequence_code 3 Then we don't need to worry about translating VTY commands to valid CTRL identifiers, and except for concatenating multiple lines the VTY commands can be run 1:1 without translation mangling in-between. Many problems gone. As line separator, ';' comes to mind from common programming languages, or '%' or '#' since those two are otherwise used for comments in the VTY and will not likely cause ambiguities. We could even send LF as line separator like: SET config network bts 0 trx 1 timeslot 0 training_sequence_code 3 so that the "value" part of the CTRL command is *exactly* the same as we would feed to a telnet client. At this point I'm asking myself again, what is the aim here -- an external program that can connect to CTRL might as well also connect to VTY and can already issue these config commands there. Is the aim to save one connection? I still have the impression that this idea is well meant but in reality misses practicality and usefulness. It's just a one-shot telnet client piped through CTRL, in the worst case with lots of mangling involved. where is the benefit? Would be nice if it made sense and things would fall into place, but AFAICT it unfortunately simply doesn't work out. VTY as we implemented it is too free-format and unstructured, we won't be able to tame it well. ~N