On Tue, 22 Jun 2010, Rainer Gerhards wrote: >> 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..."? > > I still fail to see the issue, maybe I still misunderstand. For all others > I'd like to remind that Adiscon is looking for a common format, if possible, > for all tools and Andre is concerned about the Windows tools. These do have a > static set of entities, so some problems I have with rsyslog simply do not > exist there. > > First of all, we do not necessarily need to validate the XML. And we are > discussing on a related thread about using expat in rsyslog, which seems not > to have that facility at all. So it looks like something nice to have, but > otherwise optional.
I don't think that rsyslog needs to do XML validation (since it's already going to do much more detailed validation later anyway) where I see the value in making it easy to do validation is to support external tools manipulating the config files. the more validation that can be cooked into the DTD/schema the more likely the editor can help the user create a valid config. David Lang > The "<im type=...>" approach does not provide proper validation in all cases. > The "<imtcp ...>" approach does not provide it either, when used with a > non-validating parser (but it could be more precisely validated with a > validating parser or other XML tools -- not the point here). So from the > point of validation, I think they are pretty close. > > As far as I see the code to be written, it just needs to get information from > the parser about the structure of the configuration. For a static entity set, > I assume a one-stop "generate DOM" call would be sufficient. For the more > dynamic world of rsyslog, we probably need to use SAX-like callbacks. In any > case, it is doable. > > After the config structure is clear, the apps need to interpret it and > generate the app-specific actual software objects instances that do the real > work. To do so, the "DOM" must be inspected and acted upon. I assume that in > this phase a number of semantic checks must also happen (so config load may > fail in that phase as well). Again, I don't see a difference in code > complexity if we use a) "<im type=..." or b) "<imtcp...". In case a), we need > to look at the entity name, in case b), we need to find and look at the type > attribute. My uneducated guess is that this is roughly equivalent amount of > work to do. > > In conclusion, I do not see any notable difference in code sizes for both > approaches. > > 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
