Considering that it hasn't been much activity around the internal libraries for long
time, I was wondering if it still makes sense to keep them like they are or merge them in
the core.
Recently, during the devel meeting, I relocated a couple of them to the archive. The
`lib/binrpc` (and `print`) can have the same fate, being not actually used.
The srdb1 is very common and I guess it is very rare the case when a deployment is used
without a module not depending on it (e.g., even if dispatcher is used with a list file,
the code is still linked to this library).
The `trie` library is small and `ims` is actually a set of getter functions for message
attribtues/headers.
The `srdb2` is not used much, but I think the right approach for it is to change the
modules using it to `libsrdb1` and get rid of it completely sometime in the future. Till
then the code is not big and can reside as part of the core.
The benefits I see are in simplifying the build system (current makefiles and hopefully
soon-to-be-merged the one based on cmake), reducing also the time to compute compile and
link dependencies; getting rid of packaging complexity (same library may be needed by
different modules, which, when packaged separately, the library has to be in a 3rd
package, or have dependency of the other module's package -- probably now the libs are
shipped with the core package).
The code for libs can stay at the same location, so source code for modules doesn't
need to be updated, just that they are compiled with the core, removing internal libs from
makefiles.
Thinking that we go for 6.0.x, clarifying the plans for this component and cleaning it, if
decided so, should fit well in such version number jump.
Opinions?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4041
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4041(a)github.com>