From: Jonathan B. <bo...@us...> - 2006-12-13 13:12:36
|
Michael, Thanks. Good response. I think I am looking at this possibility, in part, "because it's there." I am simply curious about a ctypes implementation of a Wldap32.dll pythonic interface. I also would love to see a python ldap interface that does not involve compiling multiple packages (OpenLDAP, Cyrus SASL, etc.) in order for the user to install it. This is one way of doing this, albeit only on Windows. The Wldap32.dll library is available on any Active Directory-aware Windows machine, from Windows 95 on up. This library seems to provide variety and strength of functionality. See: http://msdn2.microsoft.com/en-us/library/aa366112.aspx Another subpoint of this: I think on Windows there is a concern regarding ease of installation of a package that is really Unix-biased. On a Linux system, for instance, the distribution often has debs or rpms that easily install needed binary executables and libraries. BSD has ports. Mac has Fink. OpenLDAP, Cyrus SASL, OpenSSL and even Python-ldap are either standard or easily installed from the distribution repositories. The Windows equivalents of these libraries that Unix systems take for granted are the system dlls, like Wldap32.dll. It is already there, with the needed functionality. Ideally, I think a pure-python implementation of python-ldap is desirable (with less bloat than Twisted+ldaptor, perhaps). Until then, would the thing I am describing be something helpful? Anyway, these are some thoughts for further discussion. At this point, I am open to applying energy in any direction that makes python-ldap more Windows-friendly, as long as I have the know-how (and the time!). Regards, Jonathan Bowman On 12/12/06, Michael Str=F6der <mi...@st...> wrote: > 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. > |