on the rsyslog runtime

I had a conversation on the new runtime design for rsyslog. I think it had a quite some good technical information (and brief), so I reproduce it here: > The new design is: > rsyslog core (GPL) > rsyslog runtime (LGPL) > modules (whatever) Yes, actually I intended to say that ;) > > what is the interface between > rsyslog core/syslog-ng runtime? Pipe/linked > runtime module? Pipe/linked > The runtime always needs to be linked. A few cases: rsyslog runtime --> always linked syslog-ng/whatever runtime... linked runtime module -> linked BUT the interesting case is: rsyslog plugin -> linked or pipe syslog-ng/whatever -> linked or pipe In these cases, it depends on build parameters (all of this of course not yet implemented). I would anticipate these combinations to be found in practice: rsyslog plugin -> linked [pipe for new functionality on old engine] syslog-ng/whatever -> pipe So with rsyslog plugin, that would just a fallback if you need it for some reason (e.g. run a v3 engine with a v4 plugin WITHOUT the need to backport it [requires a v3 and v4 runtime to be present on the system, though]. For non-rsyslog syslogd's I expect that pipe is always used, because I do not think they'll change their environment to adopt to the runtime. rsyslog will provide wrappers for either interface. They will come as separate binaries. There will be an input and output plugin to allow any process (not necessarily rsyslog technology) to utilize a standard unix pipe interface for producing and consuming messages. Library modules will never use the pipe interface - it's too slow and too loosely coupled. linking offers much greater performance and is lossless. pipe is comparatively slow and may lose some messages. Pipe is obviously a much easier and thus universal interface than the plugin interface.