On Tue, 22 Jun 2010, Andre Lorbach wrote: >> -----Original Message----- >> [email protected]] On Behalf Of [email protected] >> >> 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. > > Proberly a bad term from me, "completely" is better. > If you use &#A, the XML Parser will automatically convert it into a linefeed. > But if you use \n, we need an additional step to convert the replacement > character into a linefeed.
however, since we are still going to support the legacy config format, we still need to support replacing \n with a newline, so we don't save by changing to &#A >>>>> 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. > > I agree, for readability your approach is more user friendly. But if I also > think from the parsing point of view, a generic format is easier to handle > internally. I don't care how hard the computer has to work to parse it. That's a one-time programming task and a startup-only computer task. compared to the amount of time that will be spent by humans looking at the file or editing it, it's minor. we are better off optimizing to reduce the human time than to simplify the parsing. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
