On 03/28/2012 06:39 AM, Gergely Nagy wrote:
Dmitri Pal dpal@redhat.com writes:
With the current plan we ask application developers to change things twice. First to new syslog umberlog interface and then later to a better interface. IMO this is wrong. I tried to rise the concerns about this several times but have not been heard.
I don't see it that way. First of all, umberlog can be entirely skipped, one can go - and in my opinion, should - go straight to a more flexible solution.
Second, the main purpose of umberlog is the LD_PRELOAD thing. That it has a few extras, is a side-effect, which I personally find convenient. But the main reason for the library's existence is its ability to change how syslog() works, with neither source changes, nor recompilation.
It works out of the box, it's simple, it's available already. That's what umberlog is about.
IMO we need to define one interface that the application developers would use and start to migrate to and then evolve the infrastructure under it.
That's a commendable goal, but it takes time, and coming up with an interface that most like, is non-trivial at best. That also does not help legacy applications..
Consider the scenario, where we have an amazing library that makes structured logging the most intuitive thing ever, after the nipple, and more and more applications begin to embrace and use it. But! There are still legacy applications out there that use plain old syslog(). We gotta do something about those, too, otherwise it becomes a bit of a pain to process both kind of logs.
Umberlog fills that void. It's a help for legacy apps first and foremost.
OK this statement even more prooves that we need to move on both fronts in parallel. And deliver two options at the same time or close so that people have a choice and leap if they want to bite a bullet or take a slow approach if it fits their needs.