python-ldap-dev — discussion among developers

FYI: Linuxtag 2007 and LDAPcon 2007

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

HI!

once again OpenLDAP will be presented by a team of volunteers at
Linuxtag 2007 in Berlin, Germany.

  http://www.linuxtag.org/2007/

Several deployment scenarios based on OpenLDAP will be demonstrated with
various LDAP clients.

I will also present web2ldap and answer questions about python-ldap too.
I'd be glad to meet members of the community personally there.

I'd also like to inform everybody here about a LDAP directory conference
being held at September 06/07, 2007 in Cologne, Germany.

If you'd like to present your work please see call for papers on the
conference's web site:

  http://www.guug.de/veranstaltungen/ldapcon2007/

I'd be glad to meet some of you there.

Ciao, Michael.

-- 
Michael Ströder
E-Mail: mi...@st...
http://www.stroeder.com

Re: compiled ldap libs for win32/python 2.5

[Mauro C. <mci...@li...>]

Ross McKerchar wrote:
> Statements like 'Cyrus SASL on Windows is still laregely a "work in progress"' and Jonathan Bowman's experiences (http://sourceforge.net/mailarchive/message.php?msg_name=7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0%40mail.gmail.com) 
> suggest that I am very unlikely to succesfully navigate my with through such unfamiliar territory in a reasonable time-frame.
>   

I have built Python-LDAP on Windows in the past, and this should just 
mean that you'd have to exclude SASL from the targets, i.e. no support 
for SASL on Windows (just as Michael correctly pointed out).
How unfortunate this could be in your situation, I don't know.

> Alternatively I am willing to be persuaded that the DIY option isn't as tricky as appears, so if someone is willing to offer me some extended pointers they would be greatly appreciated.

It isn't _really_ tricky, at least not as tricky as it used to be when 
OpenLDAP didn't support Windows natively.
Now it's just a matter of downloading the sources (Python, OpenLDAP, 
OpenSSL, BDB, Python-LDAP), setting up your MinGW build environment, and 
launching "make" (wait a while).
Note that you don't need to build Python, nor BDB, but you'll need some 
headers; and you'll only need shared libraries, headers and libs from 
OpenLDAP and OpenSSL, not the whole OpenLDAP thing (most of all not 
slurpd, which did not build at all on my Windows box last time).

The whole activity does take a while, though, last time I could afford 
the time I used a couple days interspersed in a week of real work.

HTH
Mauro

Re: compiled ldap libs for win32/python 2.5

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

David Leonard wrote:
>  it might be possible to modify python-ldap to work with wldap32.dll and
> avoid openldap on win32.

We had a thread on this list with subject "winldap?" back in 12/2006.

My main concern is who is going to provide *continous* support for this?
Personally I can't. Also I suspect that different versions of
wldap32.dll have different feature sets. I don't have enough knowledge
about that.

> python's distutils supports mingw, so this path looks quite attractive.

I don't want to hold anybody back, but I'd like to remind everybody
hacking in this direction to think about who is going to maintain this
code for the next two years or so. I'd suggest to create a completely
separate C module called _winldap for that purpose.

And given that we e.g. added support for OpenLDAP's ldap_str2dn() the
gap between OpenLDAP libs and other vendor's LDAP libs gets bigger. And
how about extended controls?

Ciao, Michael.

Re: compiled ldap libs for win32/python 2.5

[David L. <d...@ad...>]

it might be possible to modify python-ldap to work with wldap32.dll and 
avoid openldap on win32.
(see 'references' at http://msdn2.microsoft.com/en-us/library/aa367008.aspx)
mingw comes with a winldap.h, but I don't know how close it is to the 
one that comes from the official platform sdk headers.
python's distutils supports mingw, so this path looks quite attractive.

d

Michael Ströder wrote:
> Ross McKerchar wrote:
>   
>> Michael Ströder wrote:
>>     
>>>> I am curious as I have a win32/2.5 based app that could really do
>>>> with some ldap functionality and if I can get the current status of
>>>> project then I'll be in a better position to help...
>>>>         
>>> Your help would be appreciated. Probably using MingW?
>>>       
>> I've just been investigating this and, although I'm not a complete
>> stranger to building with MingW, my initial findings are that I'm a bit
>> out of my depth. Statements like 'Cyrus SASL on Windows is still
>> laregely a "work in progress"'
>>     
>
> You'd probably should start asking on openldap-software mailing list how
> to build OpenLDAP client libs and all required libs for Win32 with MingW
> (MSYS). Symas is doing this.
>
> Rich Megginson wrote this:
> http://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows
>
> See also current related discussion in news:mozilla.dev.tech.ldap
>
> 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
>
>   


-- 
David Leonard                           d...@ad...
                                        Ph:+61 404 844 850

Re: compiled ldap libs for win32/python 2.5

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

Ross McKerchar wrote:
> Michael Ströder wrote:
>>> I am curious as I have a win32/2.5 based app that could really do
>>> with some ldap functionality and if I can get the current status of
>>> project then I'll be in a better position to help...
>>
>> Your help would be appreciated. Probably using MingW?
> 
> I've just been investigating this and, although I'm not a complete
> stranger to building with MingW, my initial findings are that I'm a bit
> out of my depth. Statements like 'Cyrus SASL on Windows is still
> laregely a "work in progress"'

You'd probably should start asking on openldap-software mailing list how
to build OpenLDAP client libs and all required libs for Win32 with MingW
(MSYS). Symas is doing this.

Rich Megginson wrote this:
http://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows

See also current related discussion in news:mozilla.dev.tech.ldap

Ciao, Michael.

Re: compiled ldap libs for win32/python 2.5

[Ross M. <it...@cr...>]

Michael Ströder wrote:
>> I am curious as I have a win32/2.5 based app that could really do with 
>> some ldap functionality and if I can get the current status of project 
>> then I'll be in a better position to help...
> 
> Your help would be appreciated. Probably using MingW?

Hi Michael,

I've just been investigating this and, although I'm not a complete 
stranger to building with MingW, my initial findings are that I'm a bit 
out of my depth. Statements like 'Cyrus SASL on Windows is still 
laregely a "work in progress"' and Jonathan Bowman's experiences 
(http://sourceforge.net/mailarchive/message.php?msg_name=7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0%40mail.gmail.com) 
suggest that I am very unlikely to succesfully navigate my with through 
such unfamiliar territory in a reasonable time-frame.

I am, however, in a position to offer a donation to the project, if that 
would allow someone with more experience than me to complete the build 
(any takers?).

Alternatively I am willing to be persuaded that the DIY option isn't as 
tricky as appears, so if someone is willing to offer me some extended 
pointers they would be greatly appreciated.

-ross

Re: compiled ldap libs for win32/python 2.5

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

Ross,

Ross McKerchar wrote:
> 
> 1) Is it simply a case of getting someone to compile the current 
> development code or is extra work needed on the codebase?

There should not be any effort needed on the codebase.

> 2) Is there a roadmap or commitment from anyone for releasing a win32 
> package in the future?

Some people did Win32 builds before. But they did not keep up with
Python and python-ldap development. And the builds did not support SASL
functionality.

> I am curious as I have a win32/2.5 based app that could really do with 
> some ldap functionality and if I can get the current status of project 
> then I'll be in a better position to help...

Your help would be appreciated. Probably using MingW?

Ciao, Michael.

compiled ldap libs for win32/python 2.5

[Ross M. <it...@cr...>]

Hi,

I've read a few posts about this already on the mailing list but nothing 
conclusive. Could somebody confirm for me:

1) Is it simply a case of getting someone to compile the current 
development code or is extra work needed on the codebase?
2) Is there a roadmap or commitment from anyone for releasing a win32 
package in the future?

I am curious as I have a win32/2.5 based app that could really do with 
some ldap functionality and if I can get the current status of project 
then I'll be in a better position to help...

-ross

ANN: python-ldap-2.3.0

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

Find a new release of python-ldap:

  http://python-ldap.sourceforge.net/

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.3.0 2007-03-27

Changes since 2.2.1:

* OpenLDAP 2.3+ required now to build.
* Added support for Cancel operation ext. op. if supported
in OpenLDAP API of the libs used for the build.

Modules/
* Removed deprecated code for setting options by name
* Added l_ldap_cancel()
* Some modifications related to PEP 353 for
  Python 2.5 on 64-bit platforms (see SF#1467529, thanks to Matej)
* Added new function l_ldap_str2dn(), removed functions
  l_ldap_explode_dn() and l_ldap_explode_rdn()
  (see SF#1657848, thanks to David)

Lib/
* Added method ldapobject.LDAPObject.cancel()
* ldap.schema.subentry.urlfetch() now can do non-anonymous
  simple bind if the LDAP URL provided contains extensions
  'bindname' and 'X-BINDPW'. (see SF#1589206)
* ldap.filter.escape_filter_chars() has new a key-word argument
  escape_mode now which defines which chars to be escaped
  (see SF#1193271).
* Various important fixes to ldapobject.ReconnectLDAPObject
* Moved all DN-related functions to sub-module ldap.dn,
  import them in ldap.functions for backward compability
* ldap.dn.explode_dn() and ldap.dn.explode_rdn() use the new
  wrapper function ldap.dn.str2dn() (related to SF#1657848)
* changetype issue partially fixed (see SF#1683746)

Re: Preparing python-ldap 2.3

[Alain S. <asp...@gm...>]

It works for me

BR

On 3/26/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> >
> > I removed the dn2str definition from ./Modules/functions.c and now it w=
orks
>
> Thanks committed it.
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Preparing python-ldap 2.3

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

Alain Spineux wrote:
> 
> I removed the dn2str definition from ./Modules/functions.c and now it works

Thanks committed it.

Ciao, Michael.

Re: Preparing python-ldap 2.3

[Alain S. <asp...@gm...>]

I get this error

# gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=3D2 -fexceptions -fstack-protector
--param=3Dssp-buffer-size=3D4 -m32 -march=3Di386 -mtune=3Dgeneric
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC -DHAVE_LIBLDAP_R
-DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=3D2.3 -IModules
-I/usr/local/openldap-2.3/include -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/functions.c -o build/temp.linux-i686-2.=
4
/Modules/functions.o
Modules/functions.c:143: error: 'l_ldap_dn2str' undeclared here (not in a
function)

regarding

# grep -ir dn2str .
....
./Lib/ldap/dn.py:def dn2str(dn):
./Modules/functions.c:    { "dn2str",
(PyCFunction)l_ldap_dn2str,        METH_VARARGS },

I removed the dn2str definition from ./Modules/functions.c and now it works

BR

On 3/23/07, Michael Str=F6der <mi...@st...> wrote:
>
> HI!
>
> Thanks to David we made good progress getting current HEAD code updated
> to reflect changes in OpenLDAP's C SDK.
>
> I'd like to release 2.3 soon since there are some important improvements
> in HEAD but not yet released. Therefore testing of HEAD is needed!
>
> Please provide feedback ideally on the mailing list. Thanks.
>
> Ciao, Michael.
>
> Current CHANGES:
>
> ----------------------------------------------------------------
> Released 2.3.0 2007-03-xx
>
> Changes since 2.2.1:
>
> * OpenLDAP 2.3+ required now to build.
> * Added support for Cancel operation ext. op. if supported
> in OpenLDAP API of the libs used for the build.
>
> Modules/
> * Removed deprecated code for setting options by name
> * Added l_ldap_cancel()
> * Some modifications related to PEP 353 for
>   Python 2.5 on 64-bit platforms (see SF#1467529)
> * Added new function l_ldap_str2dn(), removed functions
>   l_ldap_explode_dn() and l_ldap_explode_rdn() (see SF#1657848)
>
> Lib/
> * Added method ldapobject.LDAPObject.cancel()
> * ldap.schema.subentry.urlfetch() now can do non-anonymous
>   simple bind if the LDAP URL provided contains extensions
>   'bindname' and 'X-BINDPW'. (see SF#1589206)
> * ldap.filter.escape_filter_chars() has new a key-word argument
>   escape_mode now which defines which chars to be escaped
>   (see SF#1193271).
> * Various important fixes to ldapobject.ReconnectLDAPObject
> * Moved all DN-related functions to sub-module ldap.dn,
>   import them in ldap.functions for backward compability
> * ldap.dn.explode_dn() and ldap.dn.explode_rdn() use the new
>   wrapper function ldap.dn.str2dn() (related to SF#1657848)
> * changetype issue partially fixed (see SF#1683746)
>
> -------------------------------------------------------------------------
> 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=3D=
DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>



--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Python 2.5

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

Blyth A J C (AT) wrote:
> 
> Is there a version of LDAP that works with Python 2.5?

Current CHANGES from CVS HEAD says it all (see relevant excerpts below).
2.3.0 is yet to be released. Testing especially on exotic platforms is
appreciated.

Ciao, Michael.

----------------------------------------------------------------
Released 2.3.0 2007-03-xx

Changes since 2.2.1:

Modules/
[..]
* Some modifications related to PEP 353 for
  Python 2.5 on 64-bit platforms (see SF#1467529)
[..]
----------------------------------------------------------------
Released 2.2.1 2006-11-15

Changes since 2.2.0:

Modules/
* Fix for Python 2.5 free(): invalid pointer (see SF#1575329)
[..]

Python 2.5

[Blyth A J C \(AT\) <ajc...@gl...>]

Is there a version of LDAP that works with Python 2.5?

=20

=20

Andrew

Preparing python-ldap 2.3

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

HI!

Thanks to David we made good progress getting current HEAD code updated
to reflect changes in OpenLDAP's C SDK.

I'd like to release 2.3 soon since there are some important improvements
in HEAD but not yet released. Therefore testing of HEAD is needed!

Please provide feedback ideally on the mailing list. Thanks.

Ciao, Michael.

Current CHANGES:

----------------------------------------------------------------
Released 2.3.0 2007-03-xx

Changes since 2.2.1:

* OpenLDAP 2.3+ required now to build.
* Added support for Cancel operation ext. op. if supported
in OpenLDAP API of the libs used for the build.

Modules/
* Removed deprecated code for setting options by name
* Added l_ldap_cancel()
* Some modifications related to PEP 353 for
  Python 2.5 on 64-bit platforms (see SF#1467529)
* Added new function l_ldap_str2dn(), removed functions
  l_ldap_explode_dn() and l_ldap_explode_rdn() (see SF#1657848)

Lib/
* Added method ldapobject.LDAPObject.cancel()
* ldap.schema.subentry.urlfetch() now can do non-anonymous
  simple bind if the LDAP URL provided contains extensions
  'bindname' and 'X-BINDPW'. (see SF#1589206)
* ldap.filter.escape_filter_chars() has new a key-word argument
  escape_mode now which defines which chars to be escaped
  (see SF#1193271).
* Various important fixes to ldapobject.ReconnectLDAPObject
* Moved all DN-related functions to sub-module ldap.dn,
  import them in ldap.functions for backward compability
* ldap.dn.explode_dn() and ldap.dn.explode_rdn() use the new
  wrapper function ldap.dn.str2dn() (related to SF#1657848)
* changetype issue partially fixed (see SF#1683746)

Re: Any volunteers for SF#1657848?

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

Michael Ströder wrote:
> 
> Frankly we don't need l_ldap_dn2str() at all. We can easily write
> efficient pure Python code for it with '='.join() etc.

See pure Python implementation ldap.dn.dn2str() in HEAD.

Well, this function name is somewhat misleading but let's stick to
OpenLDAP's naming convention here.

Ciao, Michael.

Re: Any volunteers for SF#1657848?

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

David,

I've committed various changes related to this. Everybody please test.

Despite the corner-cases listed before ldap.explode_dn() and
ldap.explode_rdn() should work nearly as before.

Ciao, Michael.

Re: Any volunteers for SF#1657848?

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

David,

hope you don't mind that I'm Cc:-ing the list.

David Leonard wrote:
> 
> Mmm as LDAPDN doesn't seem to be used in any other part of the C API,

At Python level I don't care about LDAPDN at all.

> Maybe just move the explode_* impl out into python code..

That's what I'm currently doing.

Other issues:

$ python -c "import _ldap;print _ldap.str2dn('')"
Segmentation fault

$ python -c "import _ldap;print _ldap.str2dn('c=')"
[[('c', None, 1)]]
        ^^^^
IMHO this should be ''.

Ciao, Michael.

Re: Any volunteers for SF#1657848?

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

Michael Ströder wrote:
> Further trails with dn2str():

Frankly we don't need l_ldap_dn2str() at all. We can easily write
efficient pure Python code for it with '='.join() etc.

Well, ldap.dn.escape_dn_chars() could need a C part for performance.

Ciao, Michael.

Re: Any volunteers for SF#1657848?

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

David Leonard wrote:
>  here's my hackery so far.. doesn't seem to work completely though...

David, glad to here from you!
Even more glad to receive some code for python-ldap!

> this is how I test:
> $ python setup.py build
> $ PYTHONPATH=build/lib.openbsd-4.0-i386-2.3/ python -c 'import _ldap;
> print _ldap.dn2str(_ldap.str2dn("a=b,c=d;e=f"))'

1. Do we really need to expose OpenLDAP constants LDAP_DN_* etc. you
introduced in constants.c at the python-ldap's API? I'd rather vote to
through out some already existing constants since they are not needed
for Python applications.
For the ease of maintenance I'd like to keep the C part under Modules/
as sparse as possible.

2. The new functions:

>>> import _ldap
>>> _ldap.str2dn('cn=Michael Ströder,o=Blurb\, Co.')
[[('cn', 'Michael Str\xc3\xb6der', 4)], [('o', 'Blurb, Co.', 1)]]

What are the numbers? Some flags in an integer?

Further trails with dn2str():

>>> print _ldap.dn2str([[('cn', 'Michael Str\xc3\xb6der', 4)], [('o',
'Blurb, Co.', 1)]])
Modules/functions.c:160
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes exactly 1 argument (3 given)
>>> print _ldap.dn2str([[('cn', 'Michael Str\xc3\xb6der')], [('o',
'Blurb, Co.')]])
Modules/functions.c:160
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes exactly 1 argument (2 given)
>>> print _ldap.dn2str([[('cn=Michael Str\xc3\xb6der')], [('o=Blurb,
Co.')]])
Modules/functions.c:160
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: new style getargs format but argument is not a tuple
>>> print _ldap.dn2str([['cn=Michael Str\xc3\xb6der'], ['o=Blurb, Co.']])
Modules/functions.c:160
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: new style getargs format but argument is not a tuple
>>> print _ldap.dn2str(['cn=Michael Str\xc3\xb6der','o=Blurb, Co.'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ("expected seq of seq of '2+'-seq", ['cn=Michael
Str\xc3\xb6der', 'o=Blurb, Co.'])
>>>

???????

> ps - my mails to the dev list don't seem to be getting through .. i'll
> have to look at that :)

I had this also (see below). Maybe my provider fixed it...

<pyt...@li...>: host
    mail.sourceforge.net[66.35.250.206] said:
550-Callback setup failed while
    verifying <mi...@st...>
550-Called:   81.169.145.100 550-Sent:
    MAIL FROM:<>
550-Response: 503 5.1.8 Postmaster not allowed
550-The initial connection, or a HELO or MAIL FROM:<> command was
550-rejected. Refusing MAIL FROM:<> does not help fight spam, disregards
550-RFC requirements, and stops you from receiving standard bounce
550-messages. This host does not accept mail from domains whose servers
550-refuse bounces. 550 Sender verify failed (in reply to RCPT TO  command)

Ciao, Michael.

Re: Any volunteers for SF#1657848?

[Alain S. <asp...@gm...>]

I'll take a look this weekend and help if I can

On 3/20/07, Michael Str=F6der <mi...@st...> wrote:
>
> HI!
>
> I'd like to release python-ldap 2.3 within the next weeks. For this
> release I'd like to get rid of using deprecated OpenLDAP C SDK functions.
>
> Since my C skills are limited I'd appreciate if somebody could take over
> implementing a new C function l_ldap_str2dn(). I've collected my
> thoughts in the SF tracker item SF#1657848 (see current content below).
>
> Ciao, Michael.
>
> --
> Michael Str=F6der
> E-Mail: mi...@st...
> http://www.stroeder.com
>
> -------- Original Message --------
> Subject: [ python-ldap-Bugs-1657848 ] ldap_value_free() deprecated
> Date: Sun, 18 Mar 2007 04:49:49 -0700
> From: SourceForge.net <no...@so...>
> To: no...@so...
>
> Bugs item #1657848, was opened at 2007-02-12 11:16
> Message generated for change (Comment added) made by stroeder
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D102072&aid=3D165784=
8&group_id=3D2072
>
> Please note that this message will contain a full copy of the comment
> thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 8
> Private: No
> Submitted By: Michael Str=F6der (stroeder)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: ldap_value_free() deprecated
>
> Initial Comment:
> Current ldap.h lists ldap_value_free() as deprecated.
> ldap_values_free_len() shall be used instead.
>
> ----------------------------------------------------------------------
>
> >Comment By: Michael Str=F6der (stroeder)
> Date: 2007-03-18 12:49
>
> Message:
> Logged In: YES
> user_id=3D64920
> Originator: YES
>
> Hmm, since Python strings are similar to struct berval probably OpenLDAP'=
s
> function ldap_bv2dn() should be used instead ldap_str2dn() within
> l_ldap_str2dn().
>
> ----------------------------------------------------------------------
>
> Comment By: Michael Str=F6der (stroeder)
> Date: 2007-03-18 11:52
>
> Message:
> Logged In: YES
> user_id=3D64920
> Originator: YES
>
> It seems ldap_value_free() is solely used in l_ldap_explode_dn() and
> ldap_explode_rdn(). These functions in turn use OpenLDAP's functions
> ldap_explode_dn() and ldap_explode_rdn() which are also marked as
> deprecated.
>
> So the best thing is for upcoming python-ldap 2.3
> 1. to add a new function l_ldap_str2dn() to functions.c,
> 2. add a new Python wrapper function str2dn() to Lib/ldap/functions.py,
> 3. to remove l_ldap_explode_dn() and ldap_explode_rdn() from functions.c
> and
> 4. modify pure Python wrapper function explode_dn() and explode_rdn() in
> ldap.functions to use the new Python function ldap.functions.str2dn() for
> preserving backward compability.
>
> This might change the behaviour of ldap.explode_dn() to return hex-escape=
d
> chars for NON-ASCII chars. This is odd anyway so personally I don't care.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D102072&aid=3D165784=
8&group_id=3D2072
>
>
>
>
> -------------------------------------------------------------------------
> 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=3D=
DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>



--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: another odd problem... with ldap restart

[Alain S. <asp...@gm...>]

I remember, of course !
And I was thinking it was stable after applying the patch.
But leaved behind that you didn't released any new version since :-)


On 3/20/07, Michael Str=F6der <mi...@st...> wrote:
>
> Alain Spineux wrote:
> >
> > Are you advising us about the use of ReconnectLDAPObject in production
> > environment ?
>
> Alain, you were the one who started the thread
> "ReconnectLDAPObject doesn't reconnect after main failure". ;-)
>
> As I said: There are issues with ReconnectLDAPObject up to latest
> released 2.2.1. SourceForge seems very slooooowwwww at the moment....so
> I'm too tired to provide URLs.
>
> > Can you tell us more about that ?
>
> The fix committed back then wasn't released yet. You might want to grab
> patches from CVS.
>
> Ciao, Michael.
>



--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: another odd problem... with ldap restart

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

Michael Ströder wrote:
> 
> The fix committed back then wasn't released yet. You might want to grab
> patches from CVS.

http://python-ldap.cvs.sourceforge.net/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.94&r2=1.95

>From glancing over the CVS comments it seems unlikely that you can
simply grab whole ldapobject.py file from HEAD.

Ciao, Michael.

Re: another odd problem... with ldap restart

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

Alain Spineux wrote:
> 
> Are you advising us about the use of ReconnectLDAPObject in production
> environment ?

Alain, you were the one who started the thread
"ReconnectLDAPObject doesn't reconnect after main failure". ;-)

As I said: There are issues with ReconnectLDAPObject up to latest
released 2.2.1. SourceForge seems very slooooowwwww at the moment....so
I'm too tired to provide URLs.

> Can you tell us more about that ?

The fix committed back then wasn't released yet. You might want to grab
patches from CVS.

Ciao, Michael.

Re: another odd problem... with ldap restart

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

Anil Jangity wrote:
> Where is ReconnectLDAPObject documented?

In the source code. I've just implemented it for my own applications and
considered it to be experimental.

Ciao, Michael.