Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
I agree.
Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning from?
GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI>
indeed, this is not proper.
SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi
looks good!
We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.