Am 15.06.2007 um 16:52 schrieb Gavin Henry:
<quote who="Dagobert Michelsen">
> I have a reworked Perl backend almost finished. Please don't
> kick the backend out now, it should be ready in a few weeks.
I'm pretty sure that's not the plan. What sort of things are you
The current Perl backend is practically unusable because of the
- every call goes through a single mutex so the backend is
- the backend has no idea of connections so requests can not
be associated to a specific bind
- binary attributes can not be passed as only zero-terminated strings
are passed to perl
- argument passing in general is cumbersome as the detailed structure
is lost via entry2str
- important entry points like 'extended' is not implemented which
is needed for ldappasswd
- there is no support for multiple databases with Perl backend
The reworked backend works as follows:
- 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
- connections are correctly tracked with individual objects
- binary attributed are correctly passed in Perl scalars
- argument passing is done in a style similar to Net::LDAP,
parsing is no longer needed as attributes and values are
- named arguments make future extensions possible
- additional information about the connection is optionally
passed as named parameter. It may be advisable later to
used magic scalars allowing access to all internal
data without the overhead of processing the arguments
ahead of time.
- entry points for connection_init, connection_destroy,
extended ops and unbind are implemented.
- multiple databases are supported.
- unimplemented entrypoints automatically return 'unwilling
- switching to old-backend-compatible-mode is done when
no connection_init method is found
What is missing:
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. I am trying
to avoid legacy compatibility code in the C part and
move that to a Perl module interposed between back-perl
and the oldstyle module. To make this as easy both for
legacy- and new users is a thing I am still working on.
Personally I dislike the idea of breaking compatibility,
however I don't know how much people actually use the
Perl backend broken as it is. The new API is designed
to be as extendable as possible to avoid incompatible
changes in the future.
The 'abandon' entry point is not implemented. That would
imply signaling between threads I haven't done yet.
I see the use of the Perl backend twofold:
(1) rapid prototyping for functionality later implemented
(2) implement complex tasks which would be too expensive
(in terms of time) to do in C
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.