On 05/17/2019 12:44 AM, William Brown wrote:
I think this would be a "final goal", so to formalise the stages:
* Add build tooling and a simple (dummy) log thread as a "getting started".
Supplement with documentation on wiki.
* Fill-in the log thread to support an "operation log", and add basic operation
log hooks in the server.
* Fill in more operation log points in the server to build detail
* change slapi_log_err to log to the new rust thread, continue to generate
* change slapi_log_audit to log to the new rust thread, continue to generate
* change slapi_log_access to log to the new rust thread, continue to generate
* remove former logging code
what I wanted to say is that right now for logging we have a split in
"what" and "how", a function wants to log something calls slapi_log_*
and provides the loglevel, type (_err, _access), and information
(formatstring and params). It does not know or care about log buffering,
log rotation, they could even all go to the same file, if it is a
dedicated thread or ....
I wonder if we really could have one api eg slapi_log_* and different
implementations, keep the current, implement a new one and allow to chose
I don't think I understand this comment, could you explain a bit more what you
have in mind?
If we want to change logging I would like to keep this separation, and
if we want to concentrate on performance we should first address the
"how" part, doin all together might be too big a task and too much work.
And we would not have to throw away the current impelmentation, it could
be configured "how" slapi_log _* perform theit task.
389-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines