Dagobert Michelsen writes:
I have a reworked Perl backend almost finished. Please don't kick the backend out now, (...)
Relax, I was not suggesting that. Something needed to be done. Glad to hear you are doing it.
- each Perl backend database has a separate Perl interpreter
- each connection gets an interpreter cloned from the specific backend. Interpreters are recycled in a pool for performance
- concurrent requests to different interpreters can run concurrently in separate threads
Is there a max number of Perl interpreters per backend? What happens if there are more long-lived connections than that?
Does a connection release its Perl interpreter to the pool if a few requests on the connection use the Perl database and then the rest of the requests use a non-Perl database?
Are you using threads created by Perl, or ldap_pvt_thread_create(), or are you somehow giving the interpreters short-lived tasks via ldap_pvt_thread_pool_submit()? There are some slapd features which can only be used if you do the latter, since that creates a "thread context" which holds thread-specific variables.
- argument passing is done in a style similar to Net::LDAP, parsing is no longer needed as attributes and values are separately stored
You might not even need to do that. Could wrap an Entry in a class which translates slapd attributes to Perl lists on demand.
- switching to old-backend-compatible-mode is done when no connection_init method is found
That sounds like a hack, one might not be interested in defining a connection_init method anyway.
The new backend is not 100% compatible to the old backend due to the lack of data sharing. This is a complex issue but maybe solvable with the help of the mod_perl code. Alternatively the code could fall back to a single interpreter when compatibility mode is on.
Unless the incompatibilities are quite small:
I think it would be a bad idea to automatically invoke an "almost- compatible" mode. Then a number of old Perl programs can break mysteriously, and maybe munge whatever data they are maintaining before it is discovered.
I suggest you make the new database fail to configure if provided an old Perl program and vice versa. And provide a trivial way to update a Perl program work both with the old back-perl and with your compat mode. One could insert a line &slapd::compat if defined &slapd::compat; or something.
I also suggest you do not let compatibility get in the way of good design decisions for the new code. If good design leads to bad compatibility, we could always put the old back-perl in contrib/back-oldperl or something.
It is still not possible to do all things from Perl which can be done in C. Exposing more datastructures and functions to Perl may even make it possible to write overlays in Perl in some distant future.
Both are possible, in particular if you provide Perl types as wrappers around the basic C types instead of translating them to arrays or hashes before delivering them to Perl. (If you've translated them it's a bit of a problem to call a number of C functions because you've lost the original data structure which you would pass _to_ the C function. Or the user has made updates in Perl structures which are not reflected in the C structures they came from. I looked into doing this with Python once, but punted since the Python C API #includes a header with Python autoconf variables which conflict with slapd's autoconf variables.