On 04.09.18 15:46, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The event_route was defined for the specific case where its name can be anything and it is a matter of modules to execute some as they need.
The interpreter which is defined in core has no clue about what names can be there. The modules cannot complain if they do not find some event_route blocks that they expect to execute, because if the event route is not found, then there should be noting executed.
Well, kamailio does not start if config includes call of a function defined in a module that is not loaded.
Similarly, modules could register their event routes at load, which would allow the interpreter to detect unknown event routes.
It may be too late to fix this, since too many modules already exists that define event routes.
The difference here is that event_route blocks are only defined, not executed from other route blocks.
You can also define a route[name] that is not executed in another blocks with route(name) and there is nothing happening, because the route block can be executed also from inside the c code with a value that can be built at runtime. One can also execute a route with a variable, like route($var(name)), so there can be no enforcement when a route block that is not executed statically to stop kamailio start up process.
You can eventually start adding to each module to rise errors if ithey don't find the expected event_routes, but must be a modparam, because the behaviour is not to execute event_route blocks if they are not defined. Something like: if modparam is set and event_route blocks are not found, rise error. Given that many modules can execute many event_route blocks in various cases, the modparam has to allow combinations of when to rise error based on what is expected to execute and what is defined...
Again, with open source there are always solutions, but someone has to invest time and find the balance between benefits, complexity and penalties to performances (in this case would be start up time, which might not be that critical). Personally I do not see major benefits to invest a lot if time to update all those modules and take care of all possible documentation just to cover mistyping cases, but if someone whats to do it, merging such features can be considered if there is no major negative impact and they do not change current behaviour.
Cheers, Daniel
Cheers, Daniel