On Thu, Mar 05, 2020 at 04:06:42PM +0000, Howard Chu wrote:
Just some initial thoughts on what a new logging daemon should do for
us:
The primary goal - we want to use a binary message format with as few format conversions
as possible between log
sender and log processor.
I'm thinking that we use message catalogs; we will need a tool to preprocess every
logging
invocation in the source tree and replace them with a integer messageID. So at runtime
only
the messageID and the message parameters need to be sent, not any plaintext.
This might not work in the place of loadable modules where you have to
deal with many catalogs etc.
How about a different proposition, we use the message format char * as
the message id, potentially sending the text over the first time it's
used. This could still break if we unload a module and a new one is
loaded in its place, but that sounds fixable.
... that's what I have so far. It's a bit worrisome because
of the additional moving parts:
message catalog creator, log server, log postprocessor. There's definitely more
complexity
here, but most of it is moved out of the runtime hot path, which is the main goal.
Suggestions?
Moving a lot of work to the log postprocessor is good.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP