Hi Harald,
A very interesting topic indeed.
Right now VTY and control interface serve three functions:
1. Configuration ("configure terminal")
2. Object manipulation (eg "subscriber IMSI .. active ...")
3. Information query with polling and traps (eg "show ..." and control interface)
A centralized configuration DB massively works with use case (1), but doesn't really fit use cases (2) and (3) IMHO. You can do it, but then it'll serve just as a proxy to the actual application and may become a quite bloated and complicated piece of code.
Running another instance of yet another daemon is also something I personally would really like to avoid looking from a user/admin perspective. Number of processes we're already running on a NITB BTS is already getting out of hand :(
So stealing an idea from FreeSWITCH and building on top of it:
Why don't we keep the configuration DB inside each app, but expose a machine readable API only? Then VTY becomes just one of many applications talking to this API on par with web-ui, scripts and whatnot.
This API could be something like JSON or something more binary (Erlang terms binary format, BERT, etc). We can even make it more REST-like with only GET/SET/NOTIFY or more RPC like with a richer set of primitives. There are pros and cons in all these approaches, but the key point is that:
1. This works with all 3 use cases above
2. It's less intrusive into the current code base (I think)
3. Allows to have a single CLI/VTY app talking to any Osmocom app. Btw, the app can know default ports of standard apps and allow connection by neg let name like:
$ osmo-cli -n osmo-bts
4. The app can still do TAB completion and help in a VTY way - FreeSWITCH handles this perfectly with its fs_cli.
What do you think? It's a completely different approach than a config DB, so I wanted to through this idea in without too much details to see if it sticks.
Please excuse typos. Written with a touchscreen keyboard.--Regards,Alexander ChemerisCTO/Founder Fairwaves, Inc.https://fairwaves.co