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.
So my *personal* ballot is that I am ready to except the cost and risk involved in requiring app developers to change code twice. I find it far too hard to do it all perfect in a single iteration. Evolve, see results, improve what was bad, start next iteration...
I think we are currently trying to much at once. Been there, done that, failed with it. Let's focus on small steps, get them accepted, build on that. The discussion reminds me on extreme programming vs. traditional software engineering approach... I tend to prefer quick refactoring of code build to be good enough for the job at hand...
Again, I do not go as far as to object another approach, but I don't like the other one either.
Rainer