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
cheers
reinhard
"Dagobert Michelsen"
<dam@baltic-online.de> Sent by: owner-openldap-devel@OpenLDAP.org
21-feb-2005 16:39
To
openldap-devel@OpenLDAP.org
cc
Subject
Proposed enhancements to
back-perl
Hi,
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
widely.
I have already implemented the parts 1-3 with the exception
of the access to connection values in connection_init.