python-ldap-dev

winldap?

[Jonathan B. <bo...@us...>]

Greetings.

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?

If anyone has worked on this, I would love to know how it worked for
you. If you think this has potential, I would be more than happy to
show you what I am working on. If it seems like something good to
include in python-ldap, I will need some advice on how best to do
this.

Thank you,
Jonathan Bowman

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.

Re: winldap?

[Jonathan B. <bo...@us...>]

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.
>

Re: winldap?

[Rich M. <ric...@gm...>]

Jonathan Bowman wrote:
> 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.
>   
Does wldap32.dll provide SSL/TLS?  Are additional DLLs required for 
that?  Are they present on every Windows install?  What about 
SASL/GSSAPI?  These are, IMHO, essential parts of any reasonable LDAP 
client.  In this day and age, every LDAP client must be able to use 
startTLS, Digest-MD5, and Kerberos auth.
> Ideally, I think a pure-python implementation of python-ldap is
> desirable (with less bloat than Twisted+ldaptor, perhaps).
That would entail a pure python LDAP layer, LDIF parsing layer, BER 
codec layer, as well as a pure SSL layer and a pure SASL/GSSAPI layer.  
For one, doing all of this in pure python would have a seriously 
negative impact on the performance.  For two, this would be duplicating 
all of the work already done to make this all work very well in C (e.g. 
doing SSL is Hard - doing SASL/GSSAPI is Hard - doing BER and LDAP is 
somewhat easier, but why reinvent the wheel?).
> Until then,
> would the thing I am describing be something helpful?
>   
Yes.  It makes sense to leverage as much of the OS resources as 
possible.  One of the problems with this approach is that wldap32 does 
not provide all of the functionality that python-ldap expects to be 
present in the underlying ldap library layer (e.g. schema parsing, 
probabliy more).  So this approach would result in a somewhat "crippled" 
(but perhaps very useful nonetheless) python-ldap.  As well as the 
aforementioned SSL and SASL concerns.
> 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öder <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.
>>
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>
>   

Re: winldap?

[Jonathan B. <bo...@us...>]

Good points.

Wldap32.dll does do ssl and sasl easily. TLS I am still trying to figure ou=
t.

I am open to pointers on how to make SASL work for python-ldap on
Windows. I know it is possible with mingw, theoretically. Do I really
need to compile OpenLDAP using cygwin, with a mingw target?

I have been functioning fine without MSYS. I guess it is time to give in.

BTW, does python-ldap use OpenLDAP for schema parsing, or does it
implement this in pure python? I thought I understood correctly that
ldap.schema is all python.

Regards,
Jonathan Bowman

On 12/13/06, Rich Megginson <ric...@gm...> wrote:

> Does wldap32.dll provide SSL/TLS?  Are additional DLLs required for
> that?  Are they present on every Windows install?  What about
> SASL/GSSAPI?  These are, IMHO, essential parts of any reasonable LDAP
> client.  In this day and age, every LDAP client must be able to use
> startTLS, Digest-MD5, and Kerberos auth.
> > Ideally, I think a pure-python implementation of python-ldap is
> > desirable (with less bloat than Twisted+ldaptor, perhaps).
> That would entail a pure python LDAP layer, LDIF parsing layer, BER
> codec layer, as well as a pure SSL layer and a pure SASL/GSSAPI layer.
> For one, doing all of this in pure python would have a seriously
> negative impact on the performance.  For two, this would be duplicating
> all of the work already done to make this all work very well in C (e.g.
> doing SSL is Hard - doing SASL/GSSAPI is Hard - doing BER and LDAP is
> somewhat easier, but why reinvent the wheel?).
> > Until then,
> > would the thing I am describing be something helpful?
> >
> Yes.  It makes sense to leverage as much of the OS resources as
> possible.  One of the problems with this approach is that wldap32 does
> not provide all of the functionality that python-ldap expects to be
> present in the underlying ldap library layer (e.g. schema parsing,
> probabliy more).  So this approach would result in a somewhat "crippled"
> (but perhaps very useful nonetheless) python-ldap.  As well as the
> aforementioned SSL and SASL concerns.
> > 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 ar=
e.
> >>
> >> 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 ol=
d
> >> Umich, Netscape and Novell LDAP libs. This was possible because most o=
f
> >> 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 oth=
er
> >> 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-i=
etf-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. s=
ee
> >> 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 oth=
er
> >> 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 situati=
on
> >> with building OpenLDAP, Cyrus-SASL, heimdal etc. based on the MingW to=
o
> >> 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 b=
y
> >> modifying behaviour of ldapobject.LDAPObject (and derived classes).
> >>
> >> Ciao, Michael.
> >>
> >>
> >
> > -----------------------------------------------------------------------=
--
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
> >
> >
>

Re: winldap?

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

Jonathan Bowman wrote:
> 
> BTW, does python-ldap use OpenLDAP for schema parsing, or does it
> implement this in pure python? I thought I understood correctly that
> ldap.schema is all python.

Yes, ldap.schema is currently pure Python. Also the modules ldif,
ldapurl, ldap.filter, ldap.dn, ldap.modlist, ldap.cidict, dsml. But ldif
is much slower than the most recent version of OpenLDAP LDIF parser. And
for performance I might re-enable the existing C wrapper for schema
parsing. Similar to automagically importing pickle or cPickle, StringIO
or cStringIO depending on availability.

Ciao, Michael.

Re: winldap?

[Jonathan B. <bo...@us...>]

Michael,

You wrote a while back:

> 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).

Would this fellow be willing to share instructions on how to do so? I
would be happy to contact him, if so.

Thanks,
Jonathan

Re: winldap?

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

Jonathan Bowman wrote:
> 
> You wrote a while back:
> 
>>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).
> 
> Would this fellow be willing to share instructions on how to do so? I
> would be happy to contact him, if so.

You could simply ask on the openldap-software mailing list.

Ciao, Michael.