Re: commit: ldap/servers/slapd/back-perl SampleLDAP.pm

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Regards,
Hallvard