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

Re: Proposed enhancements to back-perl




Dagobert,
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.
Please let me know,
Reinhard

Just that I am typing I continue however, . . . . . . If someone is feeling spammed, sorry, I plan not to continue in case of low interest.

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 ?

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



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

28-feb-2005 17:16

       
To
reinhard.e.voglmaier@gsk.com
cc
openldap-devel@OpenLDAP.org
Subject
Re: Proposed enhancements to back-perl





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