On Tue, 22 Jun 2010, Andre Lorbach wrote: >> -----Original Message----- >> [email protected]] On Behalf Of [email protected] >> >> On Mon, 21 Jun 2010, Andre Lorbach wrote: >> >>> I meant this: >>> >>> <input name=inp10515 type=imtcp> >>> <param id="listen">10514</param> >>> <param id="ruleset">remote10514</param> </input> >>> >>> Looks more readable to me as >>> <params >>> listen="10514" >>> ruleset="remote10514" >>> /> >>> >>> Also another advantage is if you have parameters that contain >>> linefeeds like message templates: >>> >>> <input name=inp10515 type=imtcp> >>> <param id="listen">10514</param> >>> <param id="template">$foo >>> >>> $bar</param> >>> </input> >> >> two things. >> >> 1. please no 'hidden' linefeeds. I much prefer seeing them explictly > specified >> with \n > > For manually editing the configfiles, I agree, but if XML is used as > foundation, I prefer to use either hidden linefeeds or XML-Complaint > replacements like &#A;
in this case where XML is just one option for the config file format, we should avoid XML specific things where possible. Since rsyslog already uses \n for the format strings, it would be a lot easier to convert configs (in either direction) between formats if we use the same thing in XML. with & < and > we have no choice, we have to escape those for XML to parse, but I would like to avoid anything else. if we were mostly text with a few tags I would absolutly agree with you, but in our case the text is very small compared to everything else. >> 2. I really don't like the <generic type=specific> approach, it makes it > hard for >> a parser to enforce the proper application syntax because it's so easy for >> things that won't make sense to the application to exist. > > I think from an internal configuration tree point of view, it is much easier > to read and parse <generic type=specific> approach than having multiple > <genspecific>. much easier to parse, but more complex to check if you have the appropriate parameters (as well as being far more verbose) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
