> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Jeff Turner > Sent: Monday, June 21, 2010 5:49 PM > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- > XML? > > XML might be better than some apache-like format because: > - editors will automatically do syntax-highlighting, which greatly > improves > readability. If you add <?xml version="1.0"?> as the first line of > xml_rsyslog.conf then editors will notice it's XML, despite the unusual > extension (I've tested vim, emacs and gedit). Editor support also gives > you > nice things like auto-intending (=G in vim) and folding. > - there are some fantastic XML validation languages - see > http://www.relaxng.org and http://www.dsdl.org. Fancy editors will > autocomplete based on the contents of these validation files. > - XML is natively unicode with a well-defined means of setting the > encoding, and parsers will handle all that for you. > > Just wondering, is it necessary to have all those 'params' elements? > Could > this: > > <input type="imtcp"><params listen="10515" ruleset="remote10515" /> > </input> > > just become: > > <input type="imtcp" listen="10515" ruleset="remote10515" />
It's a problem of namespace pollution. In the sample I gave, attributes were used for parameters which are supported by the rsyslog core, so they always exist. Those in params were module-specific. If all of them are either parameters or all are attributes, I have the problem that rsyslog may define a new parameter that someone somewhere has used as parameter inside a module, so I would potentially break compatibility. On the other hand, there are probably ways to work around this. For example, we could permit renaming of module parameter names as part of the module load definition. This is probably extra work, but may be worth the effort. Unification might be handy. > Overall though, after the initial curve I've come to quite like the old > format :) A good format is one that is optimized for common cases. For > syslog that is simple statements like: > > mail.* -/var/log/mail.log > user.* -/var/log/user.log > > which becomes very verbose under XML: > > <ruleset id="default"> > <rule> > <filter pri="mail.*"/> > <action type="omfile"> > <params file="/var/log/mail.log" sync="false"/> > </action> > </rule> > <rule> > <filter pri="user.*"/> > <action type="omfile"> > <params file="/var/log/user.log" sync="false"/> > </action> > </rule> > </ruleset> > > Anyway, if you do go the XML route I don't think the work would ever be > wasted. An XML DOM is generic enough to act as an AST for any future > formats. Anyone wanting a different format (eg. YAML or Sieve-like) can > simply generate the XML DOM and pass it in. Good point, and actually something I am thinking about. I would also love to use the current format to form the AST. This would have great benefit. Unfortunately, my first thinking about how to do this shows that it is very, very hard because we do not have proper scoping in the current format. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
