Re: Proposed enhancements to back-perl

["Dagobert Michelsen" <dam@baltic-online.de>]

Hello Rainhard,

Von reinhard.e.voglmaier@gsk.com (Mon, 28 Feb 2005 11:20:36 +0100):
> Well, I am struggling around since a bit of time on this.
> What about putting our efforts together ?

Good idea :-)

> 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.

I assume you want to implement most if this in Perl. In designing the interface
I suggest to restrict the C part to be as small as possible like it is now, just
extending it with the functionality which can not be implemented in Perl. This
includes connection management. My current implementation calls the method
connection_init on the config-object which then can return a new object each time,
pool the objects or return always the same object for each connection like it is
in the current backend. If you want connection pooling I recommend writing it
in perl on top of the barebone backend.

> 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.

I go with you in making the C structures available in Perl. However I don't
think converting all data is wise because 1) not all data is relevant in Perl
and following pointers to additional structures would impose additional work
2) converting the connection data takes some time as the structure is quite
big.

Therefore I prefer tieing a hashref with magic to the C structures. For an
example of how this can be done see
  http://search.cpan.org/~agolomsh/Solaris-NDDI-0.01/NDDI.pm

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

Ok, I already did unbind and extended, abandon can be added easily.

> 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.

The main point is the decision if the method with the OpenLDAP backend
are more like the C API or the Perl NetLDAP API. Both ways are possible.
As opposed to my first posting I think it would be best to implement the
"raw" API as close to the C structures as possible and put a Perl
class framework (like the one you suggested) on top of this. You can
then have the best of both worlds: all information available in the C API
and an interface which can easily be used by pure Perl programmers.

> 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.

Have you made a design for this? I currently work on a backend tailoring
adressbook-like LDAP access to a Postgres database. A toolkit for this
kind of work would be nice. Or did you mean something different?

You can look at the backend modifications I have already done by
applying the patch from
  http://www.familie-michelsen.de/openldap-2.2.23-back-perl-multiconn.patch


Best regards

  -- Dagobert


--
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