We currently have a feature to track and report the bind dn even when plugins make updates

http://www.port389.org/docs/389ds/design/plugin-track-bind-dn.html

What impact is this going to have? Does it make that feature obsolete?

Indentation is off :-p

Add a log message?

Okay, it doesn't make it obsolete persay, but "on by default". I think that's the best answer here.

So looking at the one design doc you mention a concern over use a version number in the function names, "_v4". To future proof this work I think we should create wrappers now, and start using the wrappers throughout the code, so when there is another version change the impact is minimal.

For example we have slapi_v4_bvarray_append() We should also create a wrapper called: slapi_bvarray_append() that will call whatever the current "versioned" function is. So we only need to update one function when we do a major version change, and not a 150 places in the code. This of course can be a separate patch, but I wanted to bring it up.

@mreynolds I think I did start adding this? And I did use them as much as possible? Did I miss some?

Because I think this is good so we can audit the API with the intent to clean our public interface in the next few years.

@mreynolds Hey mate, I think I updated this patch. Did I miss anything?

indentation is off :-)

There's still some indentation issues, and I think you should add some logging in utf8.c (see comments). Otherwise looking good!

Thanks @mreynolds I hope to tidy this up and get it merged soon then :)

Any progress here?

I think the cleanup was done, but not sure if pushed. Really, the enemy of this is "time", and I think I want to improve this patch some more (feature gate) before I really push it.

@firstyear, just curious does this patch address the annoying issues with plug-in memory leaks reported by ASAN?

Either way it would be nice to see this work continued :)

@mreynolds Very much yes :) It was one of the motivations for me to write this all that time ago, was that it made plugin structures on the server side much simpler, and with a better defined lifetime and lifecycle. It has no asan issues at all even with dynamic enable/disable. :)

edit: hit send to soon - anyway, my current plan is look at the follow ups on filter optimisation, logging, connections, then this. But I will come back to it.

@mreynolds I've revived this and got it running on master, but I think the strategy might be to break it down into smaller submissions, so that it's easier to review :)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/2638

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.