Hello,
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 doing?
The current Perl backend is practically unusable because of the following reasons:
- every call goes through a single mutex so the backend is essentially singlethreaded - 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 separately stored - 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 to perform' - 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 in C (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.
Best regards
-- Dagobert