Re: winldap?

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

Jonathan Bowman wrote:
> 
> I am interested in feedback from you regarding the possibility of the
> python-ldap project providing modules that interface with Wldap32.dll
> on Windows. I am currently working on some modules that do this based
> on the python ctypes module.
> 
> I have not tried compiling python-ldap on Windows myself, but I do
> note that the currently available win32 binary builds do not support
> SASL. Would providing an interface that uses Wldap32.dll ease the
> pressure on the rest of you to make python-ldap work with OpenLDAP
> compiled on Windows?

Jonathan, it would be helpful to also know what your personal needs are.

There are several interesting aspects raised here by your proposal:

1. Provide Win32 build of python-ldap.

2. Support SASL on Win32. (But which mechanisms?)

3. Provide continuous support for python-ldap on Win32.

4. Using ctypes for implementing the C wrapper.

For 1. to 3. IMHO this all can be achieved with today's python-ldap
based on OpenLDAP libs. But off course there has to be someone who is
familiar with building Python extension modules for Win32 preferrably
with the MingW tool chain.

Regarding 2.:
I asked Howard Chu, OpenLDAP core developer whether it's possible to
build Cyrus-SASL on Win32 based on the MingW tool chain. He said they're
doing it all the time with Symas' product. Additionally one would have
to clarify the situation for Kerberos libs (preferrably heimdal).

Regarding 4.:
I would appreciate to ease the process of adding new functions to the C
wrapper part. Personally I have no experiences with ctypes.

A short look at the history:

In former times python-ldap, in particular the C wrapper module _ldap,
already contained many ifdef statements for making it build against old
Umich, Netscape and Novell LDAP libs. This was possible because most of
these APIs mainly sticked to RFC 1823 with only few subtle differences.

RFC 1823 was sufficient at that time. But time went on and the
deficiencies of the API defined in RFC 1823 lead to Internet-draft
draft-ietf-ldapext-ldap-c-api which unfortunately never made it to RFC
status. Also this draft has its deficiencies but nevertheless is the
defacto standard in OpenLDAP today.

Quite some while ago David and me decided to throw out support for other
LDAP C APIs than OpenLDAP for several reasons:

1. The OpenLDAP libs were actively developed in opposite to the other
LDAP libs and implemented the extended API functions defined in
draft-ietf-ldapext-ldap-c-api with some handy new arguments, like
extended controls, limits and timeout values. E.g. look at declaration
of ldap_search_ext() here:

http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt

2. We wanted to strip down the C part because I am not a C programmer
and David did not have the time to maintain python-ldap anymore.
Therefore I had to make maintenance of the C part as low effort as
possible. Today the C part is half of the size.

3. The LDAP C APIs diverged dramatically regarding support for SSL and
SASL. This could no longer be handled by a few ifdef's.

4. The API for the Python application cannot be made completey
independent of the underlying C API regarding different feature sets
(also SSL and SASL) because some SASL mechs need call-back.

5. New functions appear in the OpenLDAP API every now and then (e.g. see
Cancel extended operation in the upcoming python-ldap 2.3) but not in
other LDAP C APIs.

So how to proceed?

First I don't want to hold anyone back from porting python-ldap to other
LDAP C libs. But for requirements 1. to 3. instead of taking the
wldap32.dll approach I'd prefer to try together to improve the situation
with building OpenLDAP, Cyrus-SASL, heimdal etc. based on the MingW too
chain.

Shifting to ctypes is a very interesting option. Even if the C wrapper
API changes we could provide a stable API to the Python applications by
modifying behaviour of ldapobject.LDAPObject (and derived classes).

Ciao, Michael.