Michael and all, I took me a while to craft a response to your excellent question. I have done this as a blog post so that it is easier to reference it in the future.
I suggest that everyone interested in the v3 design has a look at it, because it describes the way I am heading. If someone doesn't like that, it is now time to speak up - in a few weeks it will probably be impossible to change routes. http://rgerhards.blogspot.com/2007/12/modules-core-functionality-and-rsy slog.html Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Michael Biebl > Sent: Wednesday, December 19, 2007 5:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] backward compatibility... > > 2007/12/17, Rainer Gerhards <[EMAIL PROTECTED]>: > > Hi all, > > > > I would appreciate your feedback on backward compatibility. I have > > started to create a loadable input module interface in rsyslog v3. My > > first input module is the mark message handler (because it has almost > no > > code, so it was a good example of what needs to be done...). I have > now > > basically have finished an initial version. The interface needs to be > > changed in the longer term, but I'll postpone that until I've done a > bit > > more work on the config interface. Now I am facing a problem with > > backward compatibility: > > > > In sysklogd/rsyslog pre-v3, the -m option controls how often mark > > messages are written (with -m0 disabling this mechanism). In v3, the > > One thing I was wondering: > If you intend to shift all (even core) functionality into loadable > modules, how do do you handle things like --help or available command > line options like -m > Do you want to hardcode it or will you provide an interface, where > rsyslog will query the module about its help message and available > options. > > I'm also still a bit uncertain, if moving everything resp. core > functionality to modules is a good idea (for problems you already > mentioned). > Imho having all core functionality in a single binary is simply much > more robust and fool proof. For things like the SQL db output plugin, > the module interface is great, because it avoids to pull in large > library and package dependencies and allows to install them on a as > need basis. For other functionality I still need to recognize the > benefits. > > Rainer, could you roughly sketch, how you envision to break rsyslog > into loadable modules in v3. Which kind of functionality would be > loadable as module, which functionality do you plan to keep in the > rsyslogd binary. A listing of all (planned) modules + the provided > functionality and requirements would really help. > > Another thing: Say you move the regexp support into a separate module. > If a regexp is then used in rsyslog.conf, will you bail out with an > error, simply print a warning (which could go unnoticed and the poor > administrator doesn't know why his regexp doesn't know) or load > modules on demand. > For the latter you'd need some kind of interface to query the *.so > files for their supported functionality. I.e. the modules would export > a list of config directives it supports and rsyslog could upon startup > query each available module and create a map. > So, e.g. the ommysql module would export its support for the :ommysql: > config directive. > Whenever rsyslog finds such a config directive it could/would load the > modules on demand. > Same could be done for the command line parameters. > The imklog module would export, that it supports the -m command line > parameter. Whenever that commandline parameter is used, rsyslog would > know which module to load. > > There are only rough ideas and there is certainly still much to > consider. But what do you think about the basic idea? > > Cheers, > Michael > > Cheers, > Michael > > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
