Hi David, thanks for the very useful comments and the sample. I really like that format, it is neat and clean. But I have one main concern, and this is the only one I voice for now (most probably all the rest is just a side-effect of that root concern). inline below
> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Tuesday, June 22, 2010 1:52 PM > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- > XML? > > On Mon, 21 Jun 2010, Rainer Gerhards wrote: > > > Original: http://www.rsyslog.com/download/new_rsyslog.conf > > XML: http://www.rsyslog.com/download/xml_rsyslog.conf > > > > I wonder if there is any good argument AGAINST using XML as > "described" in > > the sample. If nobody brings up a good argument, I'll very possibly > will try > > to take the XML road and begin to look what that takes in detail. Of > course, > > it would be helpful as well if you could make yourself heard if you > like XML > > format ;). > > XML can be a good format or a horrible format depending on how it's > used. > > poorly used it is horribly verbose with lots of strange characters and > rules. > > My policy towards XML files is to do the following > > don't use generic tags with a 'type' atribute, use more specific tags > for > system defined elements. > > if something can only take an option once, that should be an attribute > to > a tag > > if something can happen multiple times, it is a separate element > > example: > > instead of > > <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? Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
