"Rainer Gerhards" rgerhards@hq.adiscon.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. 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.
We should take selog or like, polish it warp around ul_log or pure syslog and have as an interface. While developers would migrate to it we will evolve the library and syslog implementation under it to serialize and format things into JSON XML etc but developer will have to change things once.
This definitely is a valid argument, but I think we need to weigh the pros and cons. Too much change in a single instant is very hard to sell. To small steps don't make sense, either.
My personal opinion (and experience) is that smaller steps work better than larger ones. There are obviously people in the absolute opposite camp. I still think that evolution works better than revolution.
There's one more thing I would like to add, regarding the discussion about handshake and how to change/replace/extend/whatever /dev/log: why care?
I don't think there must be a single interface to get logs from one application to another, nor should we care about the transportation issue, unless in context of libc (but more on that later, in another thread).
Why? Because there's no single size that fits all. We want to be able to *work with* logs, so we need a format, or representation that makes sense, is easy to work with, and is pretty much a standard. How it arrives from the producer to the consumer, is none of our business, in my opinion.
Like Rainer, I'm not against anyone trying to go down this route, but that's a route that I, personally, do not wish to tread.