> >> -----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 ;). > > >> 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. Best regards, Andre Lorbach _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
