I also suspect that if the "new layer" issue was addressed up front it would push the design around a bit. There could be a cleaner separation between a layer that transports bytes from the point of logging to the place of storage and the layer that codes and decodes application data to and from the byte stream.
I would suggest a compromise here though as what this library is
I could not agree more :)
supposed to provide as currently implemented is greatly needed as it stands - even without this additional formatting layer. In most cases when logging comes up as a requirement for me those logs need to be conditionally and partially enabled at run-time, are used only for manual inspection without any automated tools or where quick shell scripts using grep/sed/awk suffice and there is not great big-brother enterprise infrastructure that these logs need to integrate into. So in those cases such standardized tools, even though potentially nice, are not strictly required.
Very true!
That said, I'd really like if Boost Logging or an additional extension library would provide such a layer, however I would not impose that on John as a must. On the other hand... I understand the need and would give a *nudge* in persuading him to take it on. :-)))
Oh well - I can't promise anything. I might actually take on this challenge - 'cause I really love logging - so as soon as I have some free time.
He could very well get tangled up in real-life work in the mean time,
Oh yes - busyness is a second nature to me ;) Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right