Hi all,
I have begun to lay the foundation for a well-defined rsyslog runtime
library.
I had a couple of discussions and the current (still open to change ;))
strategy is to build gradually build the runtime library as part of the
main rsyslog project. This resembles the way plugins, also individual
projects, are shipped together in the main tarball.
What convinced me to work on this route, at least for now, is some
technical advantages. Using this approach, I can incrementally work on
the runtime library. While it is useful to have, it requires quite some
effort to build a clean, abstracted runtime library. Remember the main
effort for v3 (which will lead to v4) is to create a fully modular
rsyslog subsystem. I started from the quite monolithic v2 source based
and have already extracted a great deal of objects. But this is not yet
completed - I do this work in parallel to introducing new features and
when it best fits.
Similarly, splitting off the runtime library right now would mean I
stopping feature development for a few weeks, finally cleaning up the
object model and putting it all nicely together. While it obviously
sound like the right thing from the software engineering point of view,
it sounds pretty bad from a feature perspective (bringing everything to
a halt plus introducing many new, untested, bug possibilities). So I now
believe the right route is again a compromise: I continue to add new
features, keeping the runtime idea in mind and contributing to it
whenever it is a good time to do so. For v4, of course, we should have a
full blow abstraction, because then we finally have the clean object
model.
So I will spend some limited time on initial creation of a skeleton
library, but will continue to work on rsyslog features on a fast pace. I
honestly believe this will lead to the overall best result.
Feedback is appreciated.
Thanks,
Rainer
I have begun to lay the foundation for a well-defined rsyslog runtime
library.
I had a couple of discussions and the current (still open to change ;))
strategy is to build gradually build the runtime library as part of the
main rsyslog project. This resembles the way plugins, also individual
projects, are shipped together in the main tarball.
What convinced me to work on this route, at least for now, is some
technical advantages. Using this approach, I can incrementally work on
the runtime library. While it is useful to have, it requires quite some
effort to build a clean, abstracted runtime library. Remember the main
effort for v3 (which will lead to v4) is to create a fully modular
rsyslog subsystem. I started from the quite monolithic v2 source based
and have already extracted a great deal of objects. But this is not yet
completed - I do this work in parallel to introducing new features and
when it best fits.
Similarly, splitting off the runtime library right now would mean I
stopping feature development for a few weeks, finally cleaning up the
object model and putting it all nicely together. While it obviously
sound like the right thing from the software engineering point of view,
it sounds pretty bad from a feature perspective (bringing everything to
a halt plus introducing many new, untested, bug possibilities). So I now
believe the right route is again a compromise: I continue to add new
features, keeping the runtime idea in mind and contributing to it
whenever it is a good time to do so. For v4, of course, we should have a
full blow abstraction, because then we finally have the clean object
model.
So I will spend some limited time on initial creation of a skeleton
library, but will continue to work on rsyslog features on a fast pace. I
honestly believe this will lead to the overall best result.
Feedback is appreciated.
Thanks,
Rainer