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
