> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Dienstag, 22. Juni 2010 15:35 > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- XML? > > 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. > >>> 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. Best regards, Andre Lorbach _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
