> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Tuesday, June 22, 2010 6:19 PM > To: rsyslog-users > Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format -- > XML? > > On Tue, 22 Jun 2010, Andre Lorbach wrote: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of Rainer Gerhards > >> Sent: Dienstag, 22. Juni 2010 17:42 > >> To: rsyslog-users > >> Subject: Re: [rsyslog] feedback requested: NEW rsyslog.conf format - > - XML? > >> > >>>>> 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. > >> > >> Andre, here I am not really in the same boat with you. I initially > had > > similar > >> concerns, but I don't see why this would complicate things > (especially if > > you > >> have a static set of entities). Am I overlooking something? > > > > Maybe it is because I am already seeing the additional code which > needs to be > > written when using dedicated xml-nodes for each input type instead of > having > > one input XML-tag with a type parameter, which does not necessarily > needs to > > be called "type". I have read the comments about using a XML DTD, but > if we > > are going to use the format for multiple applications, it could > become > > difficult to maintain a common version of the XML DTD. > > > > So the question is, is it that much more human read-/use- able to use > > "<imtcp..." instead of "<im type=tcp..." or "<im id=tcp..."? > > other than sharing an XML parsing library, how much overlap is there > really between the configs of the different apps you are looking to > use?
David, that a good wakeup call. Let's review where we started last week. The core intent was to craft a common config format, one primary reason was to share some code (I'd provide some to the Windows folks, I get some from the Windows folks, nice win-win situation). At that point, we thought about an Apache-like format and we thought that we need to write a parser ourselfes that creates something like a DOM in memory. Then, all apps would work on that DOM to do their app-specific config apply. Part of that initial approach was my mislike of XML formats. Then, the discussion evolved into something XMLish and finally we went to XML. That, however, means that one core reason - code sharing - is no longer a reason. We share an XML parser, but that's it. What remains is user familiarity. All tools in question are within the same domain, so knowledge with one format is useful for operators when using another tool from that family (which is not totally uncommon, thankfully). The question now remains if this remaining use case is sufficient to make compromise. I don't think so. But I think it is useful to discuss pros and cons of various formats, trying to find the best possible solution. And I have to say that I find the discussion *very, very* useful. In less than a week, we managed to shape some important decisions and I think we have come up with some good ideas and a format that looks really useful. Aaron mentioned Brainstorming, and I think these good results are due to the fact that we thought into various directions and everybody came up with those thoughts that he had at that time. I think this is the real power of this group. Still, I think we are very, very close. I hope to do some tests with real parsers soon and see how I could work with them. If that turns out to be usable, and nobody has better ideas or big concerns, I'll probably try to get the config parsing step designed. This involves re-thinking the whole config issue and one major task is if there is any chance to create the same in-memory model based on the old config. I guess this is impossible, but if it is, we could even automatically convert between old and new format. But I am getting lengthy. To phrase it short: David, you are right, we no longer have good reason to absolutely demand we can use a single format. ;) Rainer > > I do this sort of think in some utilities that I have written for > internal > use, and I find that the configs are enough different that all the > logic > (after the initial parsing) ends up being different for every app > anyway, > so it's just easier for me to say 'is there a tag X under this tag Y' > as > it would be to say 'is there a tag X with attribute Y under this tag Z' > > most of the work with XML that I do is in perl, and there I use > XML::Simple which transforms the XML document into a memory structure > (hashes of arrays of (hashes of arrays)) that I just look for what I'm > interested in. > > David Lang > _______________________________________________ > 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
