New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

[Michael <mi...@st...>]

Lorenzo,

thanks for your feedback and suggestions.

>         def mod_rdn(dn, newrdn, delete=1):
>                 _ldap.rename(dn,newrdn,None,delete)

I'm currently implementing a Python wrapper module ldap.LDAPObject
around _ldap.LDAPObject based on work already done in
ldapthreading.LDAPObject.

This allows to implement optional parameter handling without mucking
with the C code at all.

The class wrapper will have the following benefits:
- LDAPObject's to act as real Python class without having to
implement
  Pythonic behaviour in LDAPObject.c.
- Solely use the async C module methods if available. This allows
  to throw out all the boring and hard to maintain code from
LDAPObject.c 
  repeatedly calling *_s() functions of the OpenLDAP libs.
- __doc__ strings more pydoc friendly.
- Using a threadlock to serialize LDAP calls is just setting an
optional
  key-word parameter when calling functions open() or initialize().
- Easier to maintain.
- Produce trace output of LDAP calls.

Feedback appreciated! Especially all interested folks should review
ldapthreading.LDAPObject.result(). From my own experience with
web2ldap it seems to work smoothly but please do code reviews!

>    Even better, if newsuperior is made optional and defaulted to NULL,
>    the user can simply forget about mod_rdn in the long term and choose
>    between:
>         rename(dn, newrdn)
>         rename(dn, newrdn, newsuperior)

At the moment I'm not sure how LDAPv2 servers are dealing with it.
We'll see.

> 2. You are overlooking client/server controls, which I agree to keep as NULLs
>    now, but I think should in the long term get implemented and at least
>    documented as an expected API, being it like

Yes. But unfortunately I'm not a C programmer. I have no idea how to
implement LDAP controls. C hackers should jump-on-in.

Ciao, Michael.