python-ldap-dev — discussion among developers

DN parsing (was: [patch] Demo/simplebrowse.py fixes/enhancemnts)

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

David Leonard wrote:
> 
> On Wed, 19 Dec 2001, Michael Ströder typed thusly:
> 
> > Note that in X.500 DNs are usually noted from root to entry's RDN in
> > the order left-to-right. In opposite with LDAP the order from tree
> > root to entry's RDN is right-to-left (separated by comma, see RFC
> > 2253).
> 
> ahhhh... that was the cause of some of my confusion.  thanks.

Over LDAP you always get the LDAP DN string representation of the
DN. No matter if the LDAP server just acts as a gateway to a X.500
DSA or as a stand-alone LDAP server with own DB backend.

BTW: Even OpenLDAP does not do the DN parsing completely. Comparing
equality of DNs is not trivial. I thought about implementing a
Python class for that.

David, do you have a suggestion how to implement parsing DNs? E.g.
break up

'cn=Stroeder\, Mic...@st...,ou=Weird
chars\=\+\,\#,dc=stroeder,dc=com'

into a Python data structure:

[
  [
    ('cn',u'Stroeder, Michael'),
    ('mail',u'mi...@st...')
  ],
  [
    ('ou',u'Weird chars=+,#')
  ],
  [
    ('dc',u'stroeder')
  ],
  [
   ('dc',u'com')
  [,
]

Note the multi-valued RDN. See RFC 2253 for the BNF of this mess...

Ciao, Michael.

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

[David L. <dav...@it...>]

On Wed, 19 Dec 2001, Michael Str=F6der typed thusly:

> Note that in X.500 DNs are usually noted from root to entry's RDN in
> the order left-to-right. In opposite with LDAP the order from tree
> root to entry's RDN is right-to-left (separated by comma, see RFC
> 2253).

ahhhh... that was the cause of some of my confusion.  thanks.

Paul Sokolovsky wrote:
> yes, some intermediate levels may not exist, but don't you want to
> see corresponding exception with your own eyes?

mmmm.. yes - i guess its just a demo as you say :)

d
--=20
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

Re[2]: [patch] Demo/simplebrowse.py fixes/enhancemnts

[Paul S. <Pau...@te...>]

Hello David,

David Leonard wrote on Wednesday, December 19, 2001:

[]

DL> e.g.  A=a,B=b,C=c may not have as parent A=a,B=b but instead B=b,C=c.
DL> I found this out the hard way when doing some testing ..

DL> Now, I don't fully understand X.500 so maybe someone else knows a way of
DL> properly defining and implementing "cd .."?

    I understand that it's not that simple, but it's just the demo and
my hack likely fixed it a bit and added some feature ;-) . I don't
think it's a big problem anyway - yes, some intermediate levels may
not exist, but don't you want to see corresponding exception with
your own eyes? I've tested that I can get to RootDNS with it (on my
own install, it's closed on ldap://openldap.org for example), and that
I can't get above it, so it's kinda QAed ;-) .

DL> d
DL> --
DL> David Leonard                           Dav...@it...

[]


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

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

David Leonard wrote:
> 
> On Thu, 13 Dec 2001, Michael Ströder typed thusly:
> 
> > >   I like simplebrowse.py - it's kind of utility I was always missing
> > > in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> > > keeps saying "invalid command" for almost any entered one. Fix is
> > > attached.
> >
> > I've commited it.
> 
> But, the structure of DNs is not that simple. What you're saying is that
> you want to find the 'parent' object of an object. But the simple removing
> of some component of the DN isn't guaranteed to work.

???

David, you're right that DN parsing is not that simple (escaping of
special chars). Therefore I've commited a patch that uses
ldap.explode_dn(dn) instead string.split(dn,",") hoping that the
LDAP lib does it right.

But going up one level in the LDAP DN hierarchy is exactly removing
the RDN, the first DN component (first item of list returned by
ldap.explode_dn()).

> e.g.  A=a,B=b,C=c may not have as parent A=a,B=b but instead B=b,C=c.
> I found this out the hard way when doing some testing ..

Yes. The parent entry of A=a,B=b,C=c with LDAP is B=b,C=c. That's
exactly what Paul's patch is doing.

> Now, I don't fully understand X.500 so maybe someone else knows a way of
> properly defining and implementing "cd .."?

Note that in X.500 DNs are usually noted from root to entry's RDN in
the order left-to-right. In opposite with LDAP the order from tree
root to entry's RDN is right-to-left (separated by comma, see RFC
2253).

Ciao, Michael.

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

[David L. <dav...@it...>]

On Thu, 13 Dec 2001, Michael Str=F6der typed thusly:

> >   I like simplebrowse.py - it's kind of utility I was always missing
> > in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> > keeps saying "invalid command" for almost any entered one. Fix is
> > attached.
>
> I've commited it.

But, the structure of DNs is not that simple. What you're saying is that
you want to find the 'parent' object of an object. But the simple removing
of some component of the DN isn't guaranteed to work.

e.g.  A=3Da,B=3Db,C=3Dc may not have as parent A=3Da,B=3Db but instead B=3D=
b,C=3Dc.
I found this out the hard way when doing some testing ..

Now, I don't fully understand X.500 so maybe someone else knows a way of
properly defining and implementing "cd .."?

d
--=20
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

The Secret to Supercharge your MLM!

[Patricia M. <biz...@ya...>]

Discover

"The Secret to Supercharge your MLM!"=20

A must read=2E=2E=2E=20


Hi there,=20
The secret is out!=20
Here's the mail we've all been waiting for! Read carefully
and take immediate action on it!=20
I've discovered an amazing formula that will give your
MLM an enormous enrollers explosion=2E You'll benefit
hugely if you use it with YOUR primary MLM!=20
-THE ULTIMATE RECRUITMENT FORMULA-=20
So if you are already in MLM or about to get into one
this will be the most important mail you will ever read=2E=20
Right now I know people who enroll dozens in their
downlines WEEKLY using the formula I'm about to
reveal=2E=20
Fred Stege, Founder of the company enrolled
127 people within 7 day's after launching! One of his
enrollees from this batch has become top recruiter in
his company within 90 days after using this incredible
easy-to-use concept=2E=20

The NEW Formula is meant as a Front End Program to
enhance "YOUR" MLM=2E I'm NOT pitching you in any
MLM=2E
____________________________________________
In fact you may try it for absolutely FREE and you'll
get an electrifying stack of tools straight away!
____________________________________________=20

We've discovered that the majority of Qualified MLM
Leads (Prospects) all have 1 thing in common=2E=2E=2E=20
They all are looking for 3 things they desperately want
and can't get in any one 100% generic System=2E=2E=2E=20
I just know that you'll agree with these 3 things and
they are all to your advantage!=20

Let me reveal you the 3 most sought after topics first:=20
=B7 Cutting Edge MLM Information=2E
=B7 A Legitimate Proven Formula=2E
=B7 Pre Qualified Leads=2E (And how to get them for FREE)=20

Isn't that what everybody is looking for?=2E=2E
Will these topics ever go out of style?=2E=2E
Doesn't THAT Attract the Masses?=2E=2E=20
Does 'OLD SCHOOL MLM' attract the masses?=2E=2E=20

Discover "How you can EARN RESIDUAL INCOME
While Recruiting on Auto Pilot whether they join your
MLM or not!"=20

Welcome to 21st Century Massive Recruitment=2E=20
I encourage you to check the details and sign up
immediately=2E That means NOW!=20

For more info please mail to mccuullen47@zonnet=2Enl
and write your First Name + 'MORE INFO' in the subject line=2E
You'll receive further instructions immediately=2E=20

Sincerely,=20
Patricia McCuullen

P=2ES=2E
Don't forget to write your FIRST NAME + 'MORE INFO'
In Subject line!=20

P=2EP=2ES=2E
On the given site you'll find a secret that every PRO
in our industry knows and uses=2E=2E=2E
It's called: S-L-L-G: Self Liquidating Lead Generation=2E
It will Create a Huge, Electrifying Surge in Your Cash Flow=2E=20

P=2EP=2EP=2ES=2E
Find out the NEW 3 foot rule in MLM=2E "Why Old School
MLM is nearly dead=2E"=20

Re: Python parts of module ldap

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

"Jeffrey C. Ollie" wrote:
> 
> On Sat, Dec 15, 2001 at 09:31:25PM +0100, Michael Ströder wrote:
> > Jacek Konieczny wrote:
> > >
> > > On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Ströder wrote:
> > > > After checking in some of my modules below Lib/ldap/ I noticed a
> > > > serious drawback:
> > > > All modules are dependent on availability of OpenLDAP 2 libs if
> > > > located under Lib/ldap/ because of the "from _ldap import *" done in
> > > > Lib/ldap/__init__.py.
> > > >
> > > [...]
> > > >
> > > > Any opinions?
> > >
> > > Maybe you could put "from _ldap import *" in some "try:/except:" block.
> >
> > I already thought of that. But this makes error reports about
> > importing problems somewhat harder. E.g. if linking of shared libs
> > fails it's much more useful to have the original traceback instead
> > of e.g. a NameError exception afterwards. That's not good style.
> 
> What about something like:
> 
> import sys
> _ldap_import_exception = (None, None, None)
> try:
>     from _ldap import *
> except ImportError:
>     _ldap_import_exception = sys.exc_info()

Well, then it's easier to tell somebody to do a

$ python -c "import _ldap"

to track down problems.

Another issue I forgot to mention so far is that I can't reuse
constants of _ldap if importing it fails. I have to define them
separately anyway.

Hmm, I think I will stick with a separate module package.

Ciao, Michael.

Re: Python parts of module ldap

[Jeffrey C. O. <je...@ol...>]

On Sat, Dec 15, 2001 at 09:31:25PM +0100, Michael Ströder wrote:
> Jacek Konieczny wrote:
> > 
> > On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Ströder wrote:
> > > After checking in some of my modules below Lib/ldap/ I noticed a
> > > serious drawback:
> > > All modules are dependent on availability of OpenLDAP 2 libs if
> > > located under Lib/ldap/ because of the "from _ldap import *" done in
> > > Lib/ldap/__init__.py.
> > >
> > [...]
> > >
> > > Any opinions?
> > 
> > Maybe you could put "from _ldap import *" in some "try:/except:" block.
> 
> I already thought of that. But this makes error reports about
> importing problems somewhat harder. E.g. if linking of shared libs
> fails it's much more useful to have the original traceback instead
> of e.g. a NameError exception afterwards. That's not good style.

What about something like:

import sys
_ldap_import_exception = (None, None, None)
try:
    from _ldap import *
except ImportError:
    _ldap_import_exception = sys.exc_info()

Jeff

Re: Python parts of module ldap

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

Joe Little wrote:
> 
> Go one step further and use the try:except: with a variable.. ie, under some
> condition (such as a no_openldap def), do the try:except:.. otherwise,
> normal import

You mean a variable in the module's name space? Hmm, that would have
to be set by the installing routine, DistUtils in our case.

Ciao, Michael.

Re: Python parts of module ldap

[Joe L. <jl...@op...>]

Go one step further and use the try:except: with a variable.. ie, under som=
e
condition (such as a no_openldap def), do the try:except:.. otherwise,
normal import

On 12/15/01 12:31 PM, "Michael Str=F6der" <mi...@st...> wrote:

> Jacek Konieczny wrote:
>>=20
>> On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str=F6der wrote:
>>> After checking in some of my modules below Lib/ldap/ I noticed a
>>> serious drawback:
>>> All modules are dependent on availability of OpenLDAP 2 libs if
>>> located under Lib/ldap/ because of the "from _ldap import *" done in
>>> Lib/ldap/__init__.py.
>>>=20
>> [...]
>>>=20
>>> Any opinions?
>>=20
>> Maybe you could put "from _ldap import *" in some "try:/except:" block.
>=20
> I already thought of that. But this makes error reports about
> importing problems somewhat harder. E.g. if linking of shared libs
> fails it's much more useful to have the original traceback instead
> of e.g. a NameError exception afterwards. That's not good style.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Python parts of module ldap

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

Jacek Konieczny wrote:
> 
> On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Ströder wrote:
> > After checking in some of my modules below Lib/ldap/ I noticed a
> > serious drawback:
> > All modules are dependent on availability of OpenLDAP 2 libs if
> > located under Lib/ldap/ because of the "from _ldap import *" done in
> > Lib/ldap/__init__.py.
> >
> [...]
> >
> > Any opinions?
> 
> Maybe you could put "from _ldap import *" in some "try:/except:" block.

I already thought of that. But this makes error reports about
importing problems somewhat harder. E.g. if linking of shared libs
fails it's much more useful to have the original traceback instead
of e.g. a NameError exception afterwards. That's not good style.

Ciao, Michael.

Re: Python parts of module ldap

[Jacek K. <ja...@bn...>]

On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str=F6der wrote:
> After checking in some of my modules below Lib/ldap/ I noticed a
> serious drawback:
> All modules are dependent on availability of OpenLDAP 2 libs if
> located under Lib/ldap/ because of the "from _ldap import *" done in
> Lib/ldap/__init__.py.
>=20
[...]
>=20
> Any opinions?

Maybe you could put "from _ldap import *" in some "try:/except:" block.

Greets,
        Jacek

Re: Python parts of module ldap

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

Michael Ströder wrote:
> 
> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
> 
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
> 
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
> 
> Comments?

Hmm, following-up on my own request.

After checking in some of my modules below Lib/ldap/ I noticed a
serious drawback:
All modules are dependent on availability of OpenLDAP 2 libs if
located under Lib/ldap/ because of the "from _ldap import *" done in
Lib/ldap/__init__.py.

But I'm also using some of my modules separately on platforms where
the OpenLDAP 2 libs are not available. This affects mostly the
modules ldapurl, ldif, upcoming module dsml and upcoming module
containing generic filter classes. The only solution I have at the
moment is to make a new directory-based module package under Lib/ or
a new project.

Any opinions?

Ciao, Michael.

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

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

Jacek Konieczny wrote:
> 
> > Check the online demo at http://sites.inka.de:8002/web2ldap.
> > Testers welcome... ;-)
> At the moment I don't even have time to work on pydibr (or check if it
> stll works), but I will check this some day :-)

If you have already python-ldap installed (the big hurdle) running
web2ldap is just unzipping the source distribution and issuing the
command

$ python sbin/web2ldap -d off

in the unzipped directory without prior configuration. The default
config is suitable for doing something meaningful with ~80% of LDAP
servers out there.

If you don't have the time to work on your pydibr that might be a
good chance to have at least something working despite your mental
problems with web interfaces in general... ;-)

Note: The recent web2ldap snapshots need python-ldap checked out
from CVS *very* recently (mostly the same day :-).

Ciao, Michael.

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

[Jacek K. <ja...@bn...>]

On Fri, Dec 14, 2001 at 05:50:20PM +0100, Michael Str=F6der wrote:
> Hmm, then I'd like to note that http://web2ldap.de's HTML output is
> intentionally friendly to console-based web browsers like lynx and
> w3m.=20
I belive your web2ldap is a great thing, but I don't need another layer
between LDAP and UI.
And the second thing is, that I am going to use LDAP for system
administration, and I don't like mixing administration with web
(I hate WWW interfaces to network devices like switches etc.)

> Check the online demo at http://sites.inka.de:8002/web2ldap.
> Testers welcome... ;-)
At the moment I don't even have time to work on pydibr (or check if it
stll works), but I will check this some day :-)

Greets,
        Jacek

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

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

Jacek Konieczny wrote:
> 
> On Thu, Dec 13, 2001 at 10:06:25PM +0200, Paul Sokolovsky wrote:
> > Hello python-ldap-dev,
> >
> >   Since there's no patch manager on
> > http://sf.net/projects/python-ldap/ :
> >
> >   I like simplebrowse.py - it's kind of utility I was always missing
> > in my communication with LDAP ;-)
> 
> So maybe you could help me with testing my pydibr --- LDAP browser with
> curses interface.

Hmm, then I'd like to note that http://web2ldap.de's HTML output is
intentionally friendly to console-based web browsers like lynx and
w3m. Check the online demo at http://sites.inka.de:8002/web2ldap.
Testers welcome... ;-)

Ciao, Michael.

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

[Jacek K. <ja...@bn...>]

On Thu, Dec 13, 2001 at 10:06:25PM +0200, Paul Sokolovsky wrote:
> Hello python-ldap-dev,
> 
>   Since there's no patch manager on
> http://sf.net/projects/python-ldap/ :
> 
>   I like simplebrowse.py - it's kind of utility I was always missing
> in my communication with LDAP ;-) 

So maybe you could help me with testing my pydibr --- LDAP browser with
curses interface.

No release yet, but it is available on PLD's anoncvs:
cvs -d ':pserver:cv...@cv...:/cvsroot' login
(password cvs)
cvs -d ':pserver:cv...@cv...:/cvsroot' checkout pydibr

I know I should clean it up, make a release (but I am waiting for
python-ldap release) and prepare home page for this project, but 
I am a bit lazy and (at the moment) busy :-)
And I think that if there is anybody interested in such thing he is on
this list :-)

Greets,
        Jacek

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

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

Paul Sokolovsky wrote:
> 
>   I like simplebrowse.py - it's kind of utility I was always missing
> in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> keeps saying "invalid command" for almost any entered one. Fix is
> attached.

I've commited it.

Ciao, Michael.

Re: Stability of python-ldap

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

Paul Sokolovsky wrote:
> 
>       Thanks, it seems to work fine. I was looking for LDAP module to
> convert some SourceForge scripts from Perl to Python. We probably
> stick to it instead of popen()ing ldapsearch.

Well, it should be more stable than popen()ing. ;-)

The following Python modules are currently under some work and might
be subject to changes:
ldap/async.py
ldap/modlist.py
ldif.py

This shouldn't prevent you from looking into them and give feedback.
:-)

Ciao, Michael.

[patch] Demo/simplebrowse.py fixes/enhancemnts

[Paul S. <Pau...@te...>]

Hello python-ldap-dev,

  Since there's no patch manager on
http://sf.net/projects/python-ldap/ :

  I like simplebrowse.py - it's kind of utility I was always missing
in my communication with LDAP ;-) . I'm missing "cd .." though, and it
keeps saying "invalid command" for almost any entered one. Fix is
attached.

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135

Re[2]: Stability of python-ldap

[Paul S. <Pau...@te...>]

Hello Michael,

      Thanks, it seems to work fine. I was looking for LDAP module to
convert some SourceForge scripts from Perl to Python. We probably
stick to it instead of popen()ing ldapsearch.


Michael Ströder wrote on Wednesday, December 12, 2001:

MS> Paul Sokolovsky wrote:
>>
>> Michael Ströder wrote on Tuesday, December 11, 2001:
>>
>> MS> Paul Sokolovsky wrote:
>> >>
>> >>   Can the maintainers comment on stability of python-ldap? Can it be
>> >> used for production?
>>
>> MS> Which level of "production"?
>>
>>     When one can use it in a separate product without becoming
>> python-ldap hacker or bother its developers too much ;-)

MS> Look into the examples in Demo/. Please provide more programming
MS> examples if you feel the need for it. Support for LDAP with StartTLS
MS> and LDAP over SSL is currently undocumented and needs testing
MS> (especially things like certificate validation and using client
MS> certs).

>> >> If so, which CVS tag is suggested?
>>
>> MS> Depends on your OS.
>>
>>     Linux.

MS> On Linux you check out recent version and build against recent
MS> OpenLDAP 2 libs (IMHO should be 2.0.12+). There's currently not much
MS> activity in the C wrapper part. Remember not to promise Win32
MS> support to your customers at the moment (or hack OpenLDAP 2 libs
MS> into DLLs yourself).

MS> I'm currently rewriting pure-Python module ldif. Expect the API to
MS> change.

MS> Ciao, Michael.




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135

Re: Stability of python-ldap

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

Paul Sokolovsky wrote:
> 
> Michael Ströder wrote on Tuesday, December 11, 2001:
> 
> MS> Paul Sokolovsky wrote:
> >>
> >>   Can the maintainers comment on stability of python-ldap? Can it be
> >> used for production?
> 
> MS> Which level of "production"?
> 
>     When one can use it in a separate product without becoming
> python-ldap hacker or bother its developers too much ;-)

Look into the examples in Demo/. Please provide more programming
examples if you feel the need for it. Support for LDAP with StartTLS
and LDAP over SSL is currently undocumented and needs testing
(especially things like certificate validation and using client
certs).

> >> If so, which CVS tag is suggested?
> 
> MS> Depends on your OS.
> 
>     Linux.

On Linux you check out recent version and build against recent
OpenLDAP 2 libs (IMHO should be 2.0.12+). There's currently not much
activity in the C wrapper part. Remember not to promise Win32
support to your customers at the moment (or hack OpenLDAP 2 libs
into DLLs yourself).

I'm currently rewriting pure-Python module ldif. Expect the API to
change.

Ciao, Michael.

Re[2]: Stability of python-ldap

[Paul S. <Pau...@te...>]

Hello Michael,

Michael StrЖder wrote on Tuesday, December 11, 2001:

MS> Paul Sokolovsky wrote:
>>
>>   Can the maintainers comment on stability of python-ldap? Can it be
>> used for production?

MS> Which level of "production"?

    When one can use it in a separate product without becoming
python-ldap hacker or bother its developers too much ;-)

>> If so, which CVS tag is suggested?

MS> Depends on your OS.

    Linux.

>> And why there were no releases for more than year,

MS> Hmm...

MS> Ciao, Michael.


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135

Re: Stability of python-ldap

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

Grahame Bowland wrote:
> 
> I am running a patched version to add some functionality from LDAP v3
> that wasn't in the upstream release at the time, but the patches are
> relatively trivial.

Note to Paul: These patches are in recent CVS version today. I would
also state that the C wrapper module _ldap is fairly stable at the
moment. The only caveat is that the OpenLDAP 2 libs are not
available for Win32. If that is your platform you have to dig into
that.

But without further knowledge about the production task and the OS
it's not possible to give a good answer.

Ciao, Michael.

Re: Stability of python-ldap

[Grahame B. <gr...@uc...>]

On Tue, 2001-12-11 at 07:02, Paul Sokolovsky wrote:
> Hello python-ldap-dev,
> 
>   Can the maintainers comment on stability of python-ldap? Can it be
> used for production? If so, which CVS tag is suggested? And why there
> were no releases for more than year, with latest one being quite
> feature-old and good deal of development happening all the time?

I'm not a maintainer, but we do use python-ldap for a largish and fairly
critical application (along with mod-python for apache) and it's worked
flawlessly for almost a year now.

I am running a patched version to add some functionality from LDAP v3
that wasn't in the upstream release at the time, but the patches are
relatively trivial.

Cheers,
Grahame

-- 
Grahame Bowland                       Email: gr...@uc...
University Communications Services    Phone: +61 8 9380 1175
The University of Western Australia     Fax: +61 8 9380 1109
                                     CRICOS: 00126G