david@lang.hm writes:
May be I am missing something but I fail to understand how changing from syslog() function to ul_syslog() is not an application change.
it could be that I am misunderstanding things, but as I understand it, if you just do a LD_PRELOAD of umberlog with no application changes the result is log messages with structured metadata around the raw log message.
That is correct. A syslog() message with umberlog preloaded will have extra metadata, and the original message in the 'msg' field.
If the programmer wants to add additional name/value pairs they can change individual syslog() calls to ul_syslog() and pass in parameters.
Yup, correct.
I actually don't expect many people to make a lot of use of this option, but in many cases something as simple as this is really going to be the right thing to do.
Agreed.
As I see it, the end result in terms of C is going to be four possible logging calls
- syslog()
traditional interface, no app changes. structured metadata with one message field.
- ul_syslog()
syslog() with some additional name/value pairs added
- template based (ELAPI or similar)
a template that lists the names, followed by the types and values
- memory structure based
a tree structure is created pointing to the names and values. a pointer to this structure is passed to the logging call.
This last one could be a variation or replacement for ul_syslog(), and I think it would be ideal if we could hash things out so that it can be just a newer variation of ul_syslog()
I think that all of these variations are appropriate to have (with the possible combination of #2 and #4)
Agreed, with the addition that the ul_syslog() API can easily be reimplemented on top of either 3 or 4, so once 3 and/or 4 is available, the ul_syslog() part of umberlog can be provided by that library too, so anyone who used ul_syslog() until that point can easily migrate without code change (or with as minimal as changing an include), just like syslog()->umberlog works now.