Native python LDAP?

[Richard Megginson]

michael at stroeder.com wrote:

> Rich,
>
> nice to see you here. Sorry for following up so late. I'm swamped with 
> orga stuff so this rather long response took a while...
>
> Rich Megginson wrote:
>
>> Has anyone ever thought about doing a native (not based on ldap sdk 
>> binaries) python LDAP client?
>
>
> Yes, every now and then I'm thinking about this. In fact the 
> LDAPObject wrapper class was the first step towards that. Modules 
> ldap.schema, ldif and ldapurl are pure Python by purpose. I wanted to 
> reduce dependencies on LDAP C SDKs whereever I could...
>
> Actually there is 'ldaptor' which is a pure-Python LDAP implementation 
> based on Twisted. But the web site is very unclear, no docs, no 
> release history, no response from the author to my request of working 
> together, and last not least a strong dependency on Twisted. :-(

Interesting . . .

>
> There are various good reasons for reimplementing python-ldap from the 
> ground up.
>
> The RFC1823-style API still looks through the LDAPObject class letting 
> application code look very unpythonic.

Would definitely prefer to have a Python object model instead of a C API 
model.

>
> The data types returned from and passed to LDAPObject methods are not 
> specific to python-ldap:
> - list of dicts for search results

However, it is nice to be able to be able to expose those data 
structures in pure python for other applications.

> - no clear distinction between search results and search continuations
> - raw lists for change records
> etc.
>
> With LDAPControls we cannot stay away from messing with BER any 
> longer. Therefore we could reimplement much of the LDAP protocol stuff 
> following a nice object model.

Right.

>
> Compiling the various SDKs is a mess on some platforms (e.g. building 
> OpenLDAP libs on Win32). The binaries are often behind the current 
> release although some people are really doing great work providing 
> up-to-date pre-built binaries.

Right.  The Mozilla LDAP C SDK is more Windows friendly (since it is in 
Mozilla and Thunderbird).

>
> Licensing situation not suitable for contributing python-ldap to 
> Python's standard lib.
>
> etc.
>
>> Something like Net::LDAP (which is a very nice object model, even 
>> though it's perl).
>
>
> Don't know this since I never used Perl. If it's really a good object 
> model we could simply borrow from it.

You should definitely take a look at it, and the way it keeps the object 
model throughout. the various layers.
http://cpan.uwinnipeg.ca/module/Net::LDAP
and especialy the ASN.1 parser:
http://cpan.uwinnipeg.ca/module/Convert::ASN1

>
>> It depends on several modules being available.
>
>
> Yes, that's where the sadness begins...
>
>> For example, is there a python ASN.1 parser?
>
>
> The short answer: No there's no standard ASN.1 / BER / DER module for 
> Python which could just be imported by python-ldap without any 
> licensing and installation hassles.
>
> The long answer:
>
> There are some BER modules in SNMP modules. Don't know how to solve 
> the licensing issues.
>
> In web2ldap I'm using a slightly modified version of pisces.asn1 which 
> is under old CNRI license. The author planned to work out a better 
> license with CNRI but got stuck.
>
> => It boils down to developing a ASN.1 module and contribute it to 
> Python's standard libs (following licensing advice by PSF from the 
> very beginning).
>
>> Most everything else is already available in python - sockets, ssl, etc.
>
>
> Hmm, SSL support in Python's standard lib is very basic. AFAIK there's 
> no proper certificate and CRL checking at all. And there's also SASL, 
> Kerberos, etc. to think about.

I'm not sure if native python SSL support is best.  Perhaps there are 
wrappers around openssl or Mozilla NSS (which has much better support 
for CRL, OSCP, etc.).  Maybe the best thing to do would be to use SWIG 
to generate wrappers.  Just like in perl - I'm not aware of a native 
Perl SSL implementation - just wrappers around openssl.  Not sure about 
SASL either, but it seems that there would be a general need for a SASL 
module in python.  Or again, a wrapper around cyrus sasl.

As you can probably tell, I have a lot of experience with perl :-)  But 
very little with python, but I have come to realize the power and 
usefulness of python over perl for these sorts of applications.

>
> Off course I'd be willing to put work into it. But it would need 
> several developers to reach the same functional level as today's 
> python-ldap within a reasonable time frame.

Sure.

>
> Let's discuss design goals...mine are:
>
> Let's call the module 'ldap2'.
>
> 'ldap2' should go into Python's standard lib in the long run.
>
> Drop back-ward compabilty to 'ldap'. One could try to implement a 
> compability class API later but this should not be a first-time 
> requirement which then turns out to be an obstacle for a clean object 
> model.
>
> Drop support for Python versions prior 2.3 (because of sets, datetime 
> and various other modules)
>
> Add support for Unicode whereever suitable.

That sounds like the right things to do.

>
> ....to be continued...
>
> Ciao, Michael.
>
>
>