On Tue, 22 Jun 2010, [email protected] wrote: > 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
a clarification on this. if you are really doing stuff with significant amounts of text then what you re suggesting makes a lot of sense, but in rsyslog we are specifying fairly short strings that will be used as output, and for thise I think we are better off specifying everything explicitly. David Lang > 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. > > David Lang > > >> Regards, >> Andre Lorbach >> >>> -----Original Message----- >>> From: [email protected] [mailto:rsyslog- >>> [email protected]] On Behalf Of Rainer Gerhards >>> Sent: Montag, 21. Juni 2010 15:10 >>> To: rsyslog-users >>> Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- XML? >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:rsyslog- >>>> [email protected]] On Behalf Of Andre Lorbach >>>> Sent: Monday, June 21, 2010 2:57 PM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- >>>> XML? >>>> >>>> Hi, >>>> >>>> the only argument against XML I can think of is, that syntax error's >>>> might happen more often. >>>> But if you see XML as an advanced configuration language, this would >>>> be fine. >>>> >>>> >>>> Besides that I would allow and support multiple methods to express the >>>> parameters like in this sample: >>>> <input name=inp10515 type=imtcp> >>>> <params listen="10514"> >>>> <param id="ruleset">remote10514</param> >>>> </params> >>>> </input> >>>> >>>> For having only a few parameters, it is fine to have the parameters as >>>> XML-Node properties, but if you have more than a few parameters, the >>>> view is more readable if each parameter has its own XML-Node. >>> >>> I think you mean this: >>> >>> <input name=inp10515 type=imtcp> >>> <params> >>> <param id="listen">10514</param> >>> <param id="ruleset">remote10514</param> >>> </params> >>> </input> >>> >>> But what's the advantage of this over >>> >>> <input name=inp10515 type=imtcp> >>> <params >>> listen="10514" >>> ruleset="remote10514" >>> /> >>> </input> >>> >>> I have to admit that I do not see an advantage, just more text to be >> written >>> (and IMHO harder to read due to more noise). So I personally prefer the >>> paramter approach. Also I don't see why it should become less readable if >>> there are many parameters. Isn't that just a matter of how you format the >>> source text? >>> >>> Maybe I am overlooking something obvious. I don't have much experience >>> with XML... >>> >>> Rainer >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
