Anton & Albert, Please note that by providing the sample I was focussed on the length of the message. I agree with Anton that introducing line breaks is *not* a good idea. As I said, we have software that forwards Windows event log data. Let me explain a little how it deals with it - I think this is more or less a typical example in such cases.
As a matter of fact, we do have line breaks in Windows event logs. This is absolutely valid in the Windows world, as the event system follows a different paradigm (and I don't want to start a discussion on the good and evil in that - let's simply use this is a fact ;)). The event system has also other properties, like the event ID or source. As such, there is no one-to-one match to syslog concepts. However, the concepts are close enough that a mapping is possible. We do this mapping by reformatting the event log entry. While reformatting, we remove line breaks. As Anton said, if we would leave them in, that would screw up almost all analysis processes. In essence, they are also not very helpful, so there is no issue in formating them. So after our formatting we have a "plain" syslog message whom's content is Windows-specific (no big deal). At the collector, that message can be stored like any other syslog message. An analysis script can process it and find one message per line. It is even helpful in reports, because multiple lines would potentially screw those, too. Again, in reports missing line breaks cause no readability issue (you may want to look at one possible example report at http://www.mwconsole.com/en/Product/SystemStatus-15-7-2003.html - if you look at the example report you will notice that oversize messages are only very few). So what is the essence of my long wording? I, too, think we should stick with no line breaks inside the message. We will break a horrible lot of things if we change this (btw: we have prooven this with the initial versions of our software years back - before we filtered out the line breaks - so my statement is based on actual experience ;)). Rainer
