python-ldap-dev

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

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

Michael Ströder wrote:
> 
> I'm currently implementing a Python wrapper module ldap.LDAPObject
> around _ldap.LDAPObject based on work already done in
> ldapthreading.LDAPObject.

I've checked in the Python wrapper module ldap.ldapobject and
removed module ldapthreading.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/ldapobject.py

When doing

import ldap
l=ldap.open()

the new module is automagically used.

Please test and give feedback!

Ciao, Michael.

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.

Re: ldap_rename bindings

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

"Lorenzo M. Catucci" wrote:
> 
> 1. If you look into ldap.h, ldap_modrdn is deprecated, and should be
>    expressed as a rename with a null newsuperior. I think in
>    PyArg_ParseTuple( args, "sss|i", &dn, &newrdn, &newSuperior, &delold )
>    the last "s" should be a z, therefore allowing (in the future) to move
>    mod_rdn from _ldap to a back-compatibility helper in ldap.py like in
> 
>         def mod_rdn(dn, newrdn, delete=1):
>                 _ldap.rename(dn,newrdn,None,delete)
> 
>    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)

/bin/done

BTW always remember: You can do strange things with ModRDN operation
with non-leaf entries on an OpenLDAP 1.x server. You can even abuse
it to do very fast sub-tree deletion. Better called sub-tree
hiding... ;-)

Ciao, Michael.

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

[Jacek K. <ja...@bn...>]

On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Str=F6der wrote:
> I've checked in the Python wrapper module ldap.ldapobject and
> removed module ldapthreading.
[...]
>=20
> Please test and give feedback!

I found two bugs, which made my pydibr refuse to work:
- get_option() instead of set_option() in one place
- and intialize() instead of initialize() in another

I have already commited the fixed. I hope there are no more such
"typos".

Greets,
        Jacek

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

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

Jacek Konieczny wrote:
> 
> On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Ströder wrote:
> > I've checked in the Python wrapper module ldap.ldapobject and
> > removed module ldapthreading.
> [...]
> >
> > Please test and give feedback!
> 
> I found two bugs, which made my pydibr refuse to work:

Thanks for testing and fixing it!

> I have already commited the fixed. I hope there are no more such
> "typos".

Any general comments about this approach?

Ciao, Michael.

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

[Jacek K. <ja...@bn...>]

On Sat, Dec 22, 2001 at 02:48:46PM +0100, Michael Str=F6der wrote:
> > I have already commited the fixed. I hope there are no more such
> > "typos".
>=20
> Any general comments about this approach?

It seems like a very good idea.

Greets,
        Jacek