Re: set_rebind_proc

[Steffen R. <ste...@sy...>]

Michael Str=F6der <mi...@st...> writes:

[...]

> > After looking into the code I found that the "set_rebind_proc" method
> > has been disabled "until made OpenLDAP2 compatible". Since I need this
> > functionality, I have implemented an openLDAP2 compatible version of
> > set_rebind_proc.
>=20
> AFAIR there was no decision made yet in the OpenLDAP project how to
> implement set_rebind_proc. But I have to check recent status.

I guess I should have done more research and less reverse
engineering... :-)

I looked through the OpenLDAP mailing list archives and found only a
couple of messages relating to this issue. I can't say whether the
mechanism is finalized, but I've seen concerns that it should not be
implemented the way it is.

[...]

> I have to admit that I'm scared about adding such functionality into
> the C part of python-ldap. I'd like to encourage you to find a
> Python-only solution which is easier to maintain. BTW: That's exactly
> one of the benefits of class ldap.ldapobject.LDAPObject: It can be
> sub-classed for extending its functionality.

Hmm. Implementing a Python-only solution would require to catch the
ldap.REFERRAL (or ldap.PARTIAL_RESULT) for each of the operations,
decide how to chase the referral and then retry the operation. I can
try to come up with a proposal...

> > I kept the interface for the callback the same as it was for the old
> > implementation, i.e. the callback has to accept an LDAP object and
> > return a tuple (DN, CRED, METHOD).
>=20
> Please check whether this complies to what's done in OpenLDAP 2 today.

It does not. The new API call passes URL, request type and message-id. I
ignored these values (mostly because I don't have any particular use
for them...).

[...]

> I'd rather like to see a framework which helps the application
> developer to implement generic exception handlers for
> e.g. ldap.SERVER_DOWN or ldap.REFERRAL and decide what to do in
> his/her specific environment.
>=20
> We could store the last operation tried in a class attribute by just
> extending LDAPObject._ldap_call(). Hmm, adding the parameters of the
> LDAP operation which raised a LDAPError exception to the LDAPError
> exception instance itself would be really nice...

Are you thinking of registering error specific exception handlers or
pushing the functionality to the application?

I would like to add some functionality to the library (call it a
framework), rather than burden the application to wrap every
search/add/modify with an exception handler for chasing referrals. I
have this kind of code in some places for fail over, which makes it
pretty hard to maintain.

/steffen
--=20
ste...@sy...	<> Gravity is a myth -- the Earth sucks!