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