On Tue, 2010-06-22 at 14:11 +0200, Rainer Gerhards wrote: > I have a bit of a problem with the dynamic nature of rsyslog. As you know, > almost everything is loaded, so from the rsyslog core's PoV there is little > known in advance. However, the core has some "base objects", like inputs and > actions. There is common code for these and there are common properties. > Actually, rsyslog employs objects in an OO-type of manner, where e.g. input > is the super class of each of input modules, which "inherit" from it. > > The <input type="imtcp"> thing was designed with that class structure on my > mind. So I had a clear indication that this is an input and so I know where > to look up. > > If I now get <imtcp ...> I don't know immediately what I am dealing with. > Granted, I probably just need to adopt the way I look at it. Probably I need > to craft a facility where modules can register XML entity names and tell the > core what type of entity it is. Maybe I need some time to adapting to that. > > Anyhow, and as you seem to be online right now, don't you think there is a > problem with that method. Especially when thinking about rsyslog's dynamic > nature?
I think I just identified one myself. Let's assume that plugins can register xml entities. But that means that the xml parser can only be called after all plugins are loaded (because the plugins need to be loaded first). So I think the actual plugin load process could NOT be specified inside the main rsyslog.conf. Am I right here? On the other hand, it may not be a bad solution to have two config files, one for plugins to be loaded and one for the actual config. That would probably substantially reduce the complexity of a config-reload HUP (under the assumption that changes to plugins require a full restart). Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
