Re: Proposed enhancements to back-perl

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

Hallo Reinhard,

Von reinhard.e.voglmaier@gsk.com (Tue, 1 Mar 2005 09:56:57 +0100):
> I wonder if we should continue this discussion on the list, maybe there's
> nobody else than the two of us interested in the subject ? If there's
> something else interested, please comment, otherwise I would propose not
> to burden on the list.

Ok.

> 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.
>
> Yes. The C-structure however gives you already a unique connection ID,
> what about use this one ?

Yes, that's the way I did it. Please see the patch from my last posting.

> 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.
>
> Yes, I agree. That was also my concern about it. What I would like is a
> pointer from Perl to a C structure and the Perl programmer can use
> whatever he needs. However the C-struct we are speaking of is very large
> and very complex. Furthermore it introduce redundance. For example you
> call "modify" and pass to it a struct with the information inside that the
> operation is "modify". So it would be good to understand which data is
> really needed and which data not.
>
> 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
>
> For example. I heard from a person which wanted to access from the backend
> a radius server. I could hear him if he uses this solution. BTW: what
> about multithreading ??? I had problems using multithreading on SUN
> Solaris, therefore I compiled OpenLDAP without multithreading.

Works fine for me, I had trouble compiling back-perl with Perl multithreading.
The ability to have a completely multithreaded OpenLDAP with Perl
would be very nice to have.

> If however
> one would like to have it, the information which thread the Perl
> interpreter is actually used in should be passed. Furthermore Perl should
> be compiled with the -DMULTEPLICITY switch.

Multiplicity is needed when you are using more than one interpreter.
Are you thinking of using a separate interpreter for each connection?
Then you would need the thread index, otherwise I can see no advante in
using it.

In the current implementation the Perl code is running sequentially,
shielded by perl_interpreter_mutex. I am not sure what needs to be
changed for real multithreading of OpenLDAP with Perl.

Have you looked at the patched backend yet? I suggest starting from
there. For my part I can add access to the connection info. Perhaps
it is a good idea if you work on the highlevel Perl backend.


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