> On 22 May 2019, at 22:36, Ludwig Krispenz <[email protected]> wrote: > > > 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 > error file > * change slapi_log_audit to log to the new rust thread, continue to generate > audit file > * change slapi_log_access to log to the new rust thread, continue to generate > access file. > * remove former logging code > >>> 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? > 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 .... > > 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.
Sounds good. I think (?) that we agree on the design and the approach to coding this then, including the configuring the "how". Perhaps to be more specific, you'd amend the goal as: > * 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 > error file > * change slapi_log_audit to log to the new rust thread, continue to generate > audit file > * change slapi_log_access to log to the new rust thread, continue to generate > access file. ^ These three would become: * Add a configuration item for async or legacy log processing for the slapi_log_* types, default to "legacy". * Once more confident, default to "async" for slapi_log_* to use the new rust thread > * remove former logging code Is that what you had in mind? > _______________________________________________ > 389-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
