> 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.

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

Reply via email to