On Tue, 22 Jun 2010, Rainer Gerhards wrote: > Hi David, > >> >> <input type="imtcp"> >> <!-- params holds module-specific config parameters --> >> <params >> listen="10514" >> ruleset="remote10514" >> /> >> </input> >> >> do >> >> <imtcp listen="10514" ruleset="remote10514" /> > > 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?
the specifications for XML DTDs are designed to be modular, so a new definition can just be appended, that's a relativly simple thing as long as you require modules be loaded explicitly, loading the module can load the appropriate section of XML DTD definition. one other thing that you could do is to scan the available modules and end up only loading a module if there is an XML tag relevent to that module it does make it a little harder for stand-alone entities to do the checking as something needs to assemble the appropriate DTD, but I think the effort is worth it. people write new modules/config management tools fairly rarely, but they edit the config file frequently. optimize for the more common use case (editing the files) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
