> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Andre Lorbach > Sent: Tuesday, June 22, 2010 3:16 PM > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf > format -- XML? > > > >> -----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 ;).
Andre, not sure if you missed it. What David posted *is* valid XML (minus a typo in an <action> entity). I successfully parsed it with a libxml testing tool. > > > > >> 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. If you look at my last porposal and what David suggested, you'll see that my suggestion is much more verbose. Also, I find my one far harder to read, because there as so many noise words. Plus, automatic verification works far better for David's proosal (assuming that I can work properly with a SAX-type of Interface). Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
