This had multiple reasons. For one, adding new functions may add more and more dependencies, which in the end takes up a lot of memory on your computer, even if you don't plan on using any of the functions. A good example of this are hash-functions. If they were implemented to always be available, it would bloat rsyslog dependencies. However, not many users actually require hash functions, so the loss of memory would not bring any advantage.
This also led to functions (http_request being an example) not being available on many distributions, since it would require too many built-in libraries. Because of this, distributions did not provide the function, because of the dependencies (in case of http_request the curl library), causing the functions to not be usable. With the new loadable interface, this will no longer be a problem, since dedicated packages can be created. So users can decide what functions to load and can then add the needed libraries (if not already present) to their installation.
Another reason is consistency across the rsyslog project. Almost anything with the exception of script functions is loadable. Before now, making them loadable would have been unnecessary,considering that the functions are so small that loading them would take longer and make the program take up more space than just making them built in. Now however, with good options to load bigger and more complicated functions without influencing smaller systems, basically everything is loadable, as was the goal since the initial design in 2007.
However, functions can still be built in, just like omfile and other built in output modules. This is the case for all functions that existed in 8.33.1 with the exception of http_request (now available via module fmhttp). This has multiple reasons:
- they have a very small memory footprint
- changing these functions into modules would increase the footprint, since the overhead for modules would be necessary
- it would break existing configurations (else missing load statements in configuration)
Future blogpost will describe the implementation and usage of loadable function modules.