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. > > I think if we go for XML, then it should be fully and correctly used. > Otherwise it becomes difficult to use a common XML Parser to read and parse > the configuration. And if we need our to write our own Configparser, I don't > see an advantage to partitionally use XML, then we could stay with the more > readable apache approach. This is my opinion ;).
define 'fully and correctly used' what I've suggested if valid XML, beyond that there are lots of things that could be done, and what is correct varies between uses. >>>> 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) > > I agree that it is a little more difficult to read, but I don't think it > becomes much more verbose. more difficult to read is a bad thing in and of itself. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
