[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Proposed enhancements to back-perl


good to hear there's somebody else doing work on back-perl. For a lot of time I thought there's no interest at all.

Well, I am struggling around since a bit of time on this.
What about putting our efforts together ?
In the meantime I comment a little bit:

1) There's only One Object, I would call BackPerl.pm This object can hold all the config stuff. I would propose another object called ConnectionPool, holding all known connections, an Object called Connection and finally an object called results. Plus one object called Logger, which can be configured to make a Perl Log in order to keep things separate for debugging. All the calls to the C functions of back-perl deliver a C-structure holding all data about the request and take back a C-structure holding all the result details. I would map these two structure on Perl Objects. so how ?  There's a module from Marcus Holland-Moritz Convert::Binary::C which does exaclty this, Mapping Automagically C-structure to Perl Objects and back again.

2) Implement two new methods: Absolutely. Needed for session management. I would propose unbind, abandon, extended (?)

3) Don't know. For me the argument syntax is OK. If you generate the objects recycling the C structure, in this moment the syntax is fine. I did not have any problem with it, might be I have forgot something.

4) I would add another point: I would love a perl-backend which is tailored for Perl Programmers. I mean, the Perlbackend should give you a number of predefined objects, You write your own perl backend, "use"ing these predefined objects in your personalized backend, doing then exactly what needs to be done, without caring about the frontend and the C-part of the backend, kinda black box.

Please let me know if you're interested


"Dagobert Michelsen" <dam@baltic-online.de>
Sent by: owner-openldap-devel@OpenLDAP.org

21-feb-2005 16:39

Proposed enhancements to back-perl


I am currently working on an enhanced version of back-perl and I
would like to coordinate my results with the general consensus on
how the backend should look like in the future.

(1) Perl object creation on a per-connection basis

Currently exactly one object is generated from back-perl by
calling the class-method 'new' on the class specified in
slapd.config. A problem arises when bridging requests through
Net::LDAP with at least two connections with different bindings.
Because there is no way to differentiate between connections
only the most recent binding is used.

I propose to modify the API to use one Perl object per connection
to the LDAP server. There should be two new methods defined on
the backend object named connection_init and connection_destroy
called through the backend-hooks bi_connection_init and
bi_connection_destroy. The parameters to connection_init might
be a magic hash with access to the contents of the complete
slap_conn structure. The method returns a reference to the
connection object for this specific connection. Further
calls related to the connection are now called on the connection
object and not the backend object. This includes the methods
add, bind, compare, delete, modify, modrdn and search.

(2) New methods 'unbind' and 'extended'

The two callbacks 'unbind' and 'extended' already provided in the backend
callback structure should be forwarded to methods calls on connection
objects. The 'unbind' call is for the completeness of the
implementation. The 'extended' call is needed to process password
change requests with ldappasswd.

(3) Modified argument syntax

I would prefer an argument syntax which corresponds to the calling
conventions of Net::LDAP to ease bridging of requests. This means
that most options are passed as named parameters and that
values for options like 'deref' are passed as strings instead of
integer values. Additionally the data structure for modifications
should be used instead of the 'ADD', 'MODIFY' and 'DELETE' list
because the parsing might lead to errors if a value 'MODIFY'
is to be inserted (this is unlikely, however not impossible).
Net::LDAP uses named arguments for 'add' etc. pointing to
references to arrays or hashes making parsing unnecessary.

I am aware that the modifications will break compatibility with
the existing implementation. A compatibility-module might help
bridging the gap to existing code. Because I couldn't find
much code actually using the backend I assume it is not used

I have already implemented the parts 1-3 with the exception
of the access to connection values in connection_init.

Any feedback is welcome.

Best regards

 -- Dagobert Michelsen

Dagobert Michelsen (Leiter IT)          Baltic Online Computer GmbH
Alter Markt 1-2,   24103 Kiel,    +49 431 54003-0  (Fon) -99  (Fax)
Flughafenstr. 52c, 22335 Hamburg, +49 40 53299-395 (Fon) -100 (Fax)
Big Servers,    Fat Pipes,    Massive Storage,   Objects Everywhere