python-ldap-dev — discussion among developers

Re: 1.10alpha 'release'

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

Johannes Stezenbach wrote:
> 
> IMHO _ldapmodule.so + ldap.py is more flexible because it makes
> it easier to add stuff to "the ldap module" in python.
> ldapmodule.so requires enhancements to be implemented in C.

But different versions of ldap.py will be necessary when
distributing C ldap-module and ldaplib separately. It's ok if we
rename Fog's stuff to ldaplib and keep ldap.py (small wrapper
module) and _ldapmodule.so.

And due to start-up latency when doing "import ldap" with lots of
stuff imported I want to keep both separated.

But what about the problem that _ldap.__version__ is not correctly
imported by the wrapper module ldap.py with "from _ldap import *"?

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

David Leonard wrote:
> 
> if you have CVS access, please check out the new Build directory. 

Sorry, I didn't look at Build, but compilation from the top level
directory is broken:

$ ~/devel/ldapmodule/python-ldap-1.10a > make
cd Modules && make srcdir=./Modules VPATH=./Modules
make[1]: Entering directory
`/home/joe/devel/ldapmodule/python-ldap-1.10a/Modules'
make[1]: *** No rule to make target `Modules/LDAPObject.c',
needed by `LDAPObject.o'.  Stop.


Johannes

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> 1. Testing:
> I tested the version of Johannes and it seems to work. I tested all
> operations (search, modify, add, modrdn, delete). Hmm, I'm thinking
> about writing a Python script which implements the BLITS test suite
> on a defined data set. This is a pretty boring job but would ease
> testing in the future.

Please also test error conditions/exceptions. It would be nasty
if a missing INCREF/surplus DECREF would make it dump core on
error conditions.

> Can anybody else say something about how stable the current version
> is?

I just sent some minor corrections to David.

> I'm still not confident regarding the naming. IMHO the C-module
> should still be called ldapmodule.so and fog's stuff should be
> called ldaplib or whatever to be able to distribute both modules
> separately without having to mess with different ldap.py. Different
> ldap.py will cause nothing but troubles and boring FAQs by users.

IMHO _ldapmodule.so + ldap.py is more flexible because it makes
it easier to add stuff to "the ldap module" in python.
ldapmodule.so requires enhancements to be implemented in C.

But Michael's right: You *MUST* include a warning about deleting
the old ldapmodule.so (or ldap.dll) in the INSTALL/README
document. It may even be a good idea to add a micro-FAQ to the
distribution.

> And I know that there's "from _ldap import *" in ldap.py but this
> does not import _ldap.__version__ and using "from module import *"
> is bad behaviour anyway.

"from module import *" is bad in user code because it a) makes it
diffcult to see which symbol was imported from where, and b)
makes namespace collisions more likely.
But it is IMHO OK (and a common idiom) for C-wrapper/interface
modules. The added flexibility for future enhancements is
invaluable.

Johannes

Re: 1.10alpha 'release'

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

David Leonard wrote:
> 
> if you look at http://python-ldap.sourceforge.net/release.php you 
> should be wonderstruck by a 1.10alpha "release".
> 
> this has heaps of pesky memory leaks fixed,

I assume that these sources contains the patches by Johannes.

> please check out the new Build directory..

Very fine. I will make RPMs for recent S.u.S.E. Linux.

> the idea is to make a
> simple script that will build a release tarball fairly automatically.

Hmm. I have to learn the RPM-ish things but I will send the shell
scripts.

> also I revamped the documentation area and will build a spiffy looking 
> doc using the new latex macros.

Great.

This leads to the question which things have to be done before
releasing 1.10? 

1. Testing:
I tested the version of Johannes and it seems to work. I tested all
operations (search, modify, add, modrdn, delete). Hmm, I'm thinking
about writing a Python script which implements the BLITS test suite
on a defined data set. This is a pretty boring job but would ease
testing in the future.

Can anybody else say something about how stable the current version
is?

2. Update docs
This is pretty much David's job. Especially the web page on his own
page. We have to avoid that people download old python-ldap versions
and report errors afterwards.

> so far, all that the package has is whats in Lib and the _ldapmodule.

I'm still not confident regarding the naming. IMHO the C-module
should still be called ldapmodule.so and fog's stuff should be
called ldaplib or whatever to be able to distribute both modules
separately without having to mess with different ldap.py. Different
ldap.py will cause nothing but troubles and boring FAQs by users.

And I know that there's "from _ldap import *" in ldap.py but this
does not import _ldap.__version__ and using "from module import *"
is bad behaviour anyway.

3. Fog's schema stuff
I had a short look into the schema stuff and after installing
OpenLDAP 2.0beta I learned much more about schema definitions etc.
It's much more complicated as I expected and current schema support
in ldaplib is far from being close to it (hate to say this). E.g.
you have to implement some kind of OID registry and reference all
objects with numerical OIDs.

For exercise purpose I started to write my own schema modules but
got stuck by complexity. Supporting ALL features is pretty hard. I'm
still learning and thinking. The question is if it's easier going to
OpenLDAP 2.0 API with the C-module and get schema stuff from
there...

Ciao, Michael.

1.10alpha 'release'

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

if you look at http://python-ldap.sourceforge.net/release.php you should
be wonderstruck by a 1.10alpha "release".

this has heaps of pesky memory leaks fixed, and a package for OpenBSD.

if you have CVS access, please check out the new Build directory.. i'm not
very up on linux or other OSs, so if you want to contribute a directory there
for your favourite system, that would be great. the idea is to make a 
simple script that will build a release tarball fairly automatically.
i've had a go at a linux one - it seems to build on the sourceforge linux
server. python isn't installed on the freebsd server though, but when i
get time, i'll build it myself.

also I revamped the documentation area and will build a spiffy looking doc
using the new latex macros. but it has some glitches i notice.

so far, all that the package has is whats in Lib and the _ldapmodule.
fog, or whoever, if you want the rest to be installed sensibly, please
link it into the root Makefile.in.

comments?

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Memory leak patches by Johannes

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

HI!

I tested the patched python-ldap of Johannes (fixes memory leaks).
All functions seem to work. IMHO we should now focus on providing a
proper release on python-ldap.sourceforge.net before adding new
functionality or rewriting bigger parts of python-ldap.

It has high priority that people are able to download a source
tar.gz and package maintainers can make RPMs and build Windows DLLs.

Who is able to provide pre-compiled Windows modules? That's
important!

A section for pre-compiled packages should be on the web pages.

Ciao, Michael.

Re: Behaviour when object is not found

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

On Fri, 11 Aug 2000, Michael Ströder typed thusly:

> OpenLDAP 1.2.x when trying to read a non-existent entry ldapmodule
> raised exception ldap.NO_SUCH_OBJECT which is very handy to handle
> non-existing entries.
> 
> With OpenLDAP 2.0beta ldapmodule returns an empty result list
> instead which breaks existing code. I would expect that this is more
> a OpenLDAP 2.0 issue but before I start a discussion on
> ope...@op... I would like to understand exactly under
> which conditions the exception ldap.NO_SUCH_OBJECT is raised.

if ldap_search() or ldap_result() returns -1 AND the LDAP structure has 
its ld_errno field set to NO_SUCH_OBJECT, then that exception is raised.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: ldapmodule 1.9alpha

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

David Leonard wrote:
> 
> On Fri, 11 Aug 2000, Michael Ströder typed thusly:
> 
> > David Leonard wrote:
> > > i use a public ldap server to test simple stuff out on
> > > (but my favourite ones seem to have disappeared these days)
> > nldap.com and elvira.innosoft.com are well-structured servers. At
> > least it's ok for Novell when doing lot of testing on nldap.com. Not
> > sure about Innosoft's server. Maybe you want to e-mail the admins
> > there.
> 
> excellent.. these look like great resources.!

nldap.com has the X500-names test case of IMC under c=US. But a guy
of Novell told me that the server is pretty old => for testing
ldapmodule compability against bleeding edge LDAPv3 servers I would
recommend installing OpenLDAP 2.0v3 which is seems to be much
stricter than nldap.com.

Ciao, Michael.

Behaviour when object is not found

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

HI!

I'm testing ldapmodule (CVS version) with OpenLDAP 2.0beta. With
OpenLDAP 1.2.x when trying to read a non-existent entry ldapmodule
raised exception ldap.NO_SUCH_OBJECT which is very handy to handle
non-existing entries.

With OpenLDAP 2.0beta ldapmodule returns an empty result list
instead which breaks existing code. I would expect that this is more
a OpenLDAP 2.0 issue but before I start a discussion on
ope...@op... I would like to understand exactly under
which conditions the exception ldap.NO_SUCH_OBJECT is raised.

Ciao, Michael.

Re: ldapmodule 1.9alpha

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

On Fri, 11 Aug 2000, Michael Ströder typed thusly:

> David Leonard wrote:
> > i use a public ldap server to test simple stuff out on
> > (but my favourite ones seem to have disappeared these days)
> nldap.com and elvira.innosoft.com are well-structured servers. At
> least it's ok for Novell when doing lot of testing on nldap.com. Not
> sure about Innosoft's server. Maybe you want to e-mail the admins
> there.

excellent.. these look like great resources.!

> > i'm also trying to get time to add ssl support
> Yes, yes, yes! ;-)

:)

> > and track other changes 
> > to openldap-2.0a.
> openldap-2.0beta is out since a couple of days...

tsk.. i go away for a couple of days and look what happens..

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

web page

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

just a note to say that i'm hacking away at the web pages a bit.
please feel free to check out the htdocs module and add stuff that you 
think is important.

Maybe this would also be an appropriate place to add a big documentation page?
I would admire someone who would, say, automatically generate HTML 
documentation from all the docstrings from the _ldap module and check it
into the htdocs tree :) :)

and maybe an FAQ if you are feeling energetic

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Re: ldapmodule 1.9alpha

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

David Leonard wrote:
> 
> i use a public ldap server to test simple stuff out on
> (but my favourite ones seem to have disappeared these days)

nldap.com and elvira.innosoft.com are well-structured servers. At
least it's ok for Novell when doing lot of testing on nldap.com. Not
sure about Innosoft's server. Maybe you want to e-mail the admins
there.

> i'm also trying to get time to add ssl support

Yes, yes, yes! ;-)

> and track other changes 
> to openldap-2.0a.

openldap-2.0beta is out since a couple of days...

Ciao, Michael.

Re: ldapmodule 1.9alpha

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

On Fri, 11 Aug 2000, Dr. Ross Lazarus typed thusly:

> Just lately, I've been trying to track down a very aggravating memory
> leak in a big zope application I've built here. It's now a serious
> production system and the leak is steady and annoying.
> 
> I'm pretty sure that there's at least part of this leak in the above
> version of ldapmodule which I've been using for all sorts of things.
> Sadly, I just don't have the skills to track it down! 
> 
> I'm using openldap 1.2.11 (openldap-stable-20000704.tgz) and
> ldapmodule-1.9-alpha.tar.gz
> 
> To confirm the leak, I wrote an extremely dumb python script which just
> calls a useful ldap function repeatedly and keeps track of the number of
> iterations - try the attached code (please change the gory details to a
> local ldap server !!). 

wow! someone who has actually bothered to track down a leak! :)

> It leaks something like 5 bytes per cn_is call
> (open,simplebind_s,search_s,unbind_s) - this is a bit of a guess from
> noting that the process grows something of the order of 26000 bytes in
> size after about 5000 calls. I don't think it's 4 or 6 bytes per
> sequence although the margin for error is large because I'm watching top
> - might be easy to make it more accurate if needed..
> 
> You may already know about this?

i have had it mentioned, but since i'm not as into ldap as i once was, i have
to set up a server to test it out.. i kind of rely on other people to check
these things, or i use a public ldap server to test simple stuff out on
(but my favourite ones seem to have disappeared these days)

> Ah, refcounts...
> 
> I know that 4 bytes per call isn't much...but I'm doing a lot of ldap
> calls.. 

thats great! i will have to check it out a lot more carefully...

btw if you want to do some more checking, the sys.getrefcount() method
returns the number of reference counts on an object (plus 2)

	>>> sys.getrefcount(176271627861827618726817L)
	2
	>>> sys.getrefcount(None)
	141

it can be handy if you can see the reference count going up and up on
one particular object...

alternatively, it could be a memory leak in the ldap library itself... :(

> Is python-ldap ready for production use? I had a quick look but stopped
> short of doing a cvs checkout and build....
> Any suggestions welcomed...

well.... it has a few fixes. its got some expermental template code in there
(that coredumps) but if you dont touch it, it wont bite you :)

mmm, production. there are no guarantees or warranties...

i'm also trying to get time to add ssl support and track other changes to
openldap-2.0a. but then i have to start getting into gear to submit a thesis 
soon so that will probably be a big time of silence.

i'd like to get a next release out really soon, so if i build a tarball, would
you please test it out??

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Problems with LDAPmodule on sunos5

[Jarkko V. <Jar...@te...>]

I have created Zope site on Linux wich uses external methods to access LDAP.
I transferred my site to Solaris8/sunos5 but i can't manage to get
LDAPmodule working on sunos.
Finally after two days of work and with pretty slick manouvers, i managed to
build LDAPmodule (ldapmodule-1.9-alpha) on sunos, but there something wrong
in the module. 
On linux there no problems and building is easy as taking candy from
children. I did excatly the same on Sunos but module just won't work. 

with simple python script, i get following error:
    File "test_ldap_lib.py", line 1, in ?
    import sys,ldap,pprint
    ImportError: ld.so.1: python: fatal: relocation error: file
./ldapmodule.so: symbol ber_init: reference
    d symbol not found

and from Zope:

Error Type: ImportError
           Error Value: ld.so.1: /usr/local/Zope-2.2.0/bin/python: fatal:
relocation error: file
           /usr/local/Zope-2.2.0/lib/python1.5/ldapmodule.so: symbol
ber_init: referenced symbol not found

has anobody managed to build LDAPmodule on sunos5?
or can anoby give me some advice, what went wrong?

	jarkkov

Re: Name of LDIF lib module

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

ok

On Sun, 30 Jul 2000, Michael Ströder typed thusly:

> Can we keep the name of my LDIF module as ldif.py instead of
> ldiflib.py? I'm also distributing this module with web2ldap and I
> would like to have the same names for identical modules.

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Name of LDIF lib module

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

HI!

Can we keep the name of my LDIF module as ldif.py instead of
ldiflib.py? I'm also distributing this module with web2ldap and I
would like to have the same names for identical modules.

Ciao, Michael.

Re: web page

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

David Leonard wrote:
> 
> who wants to make the web page pretty?

Hmm...depends on what you think is "pretty". Does the web server at
SourceForge support SSI (server side includes)? Would ease things
like navigation bar etc.

> i'm working towards having a release (1.10) by next weekend.

Fine.

Ciao, Michael.

web page

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

who wants to make the web page pretty?
i'm working towards having a release (1.10) by next weekend.

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: directory structure changed

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

David Leonard wrote:
> 
> I tend to use 'cvs up -PAd' which deletes empty directories..

I tend to use it like a beginner starting from description on 
http://sourceforge.net/cvs/?group_id=2072

Also
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/?cvsroot=python-ldap
should look tidy after the directory clean-up.

If you have problems with removing directories completely it's
better to contact the SourceForge support at
http://sourceforge.net/staff.php.

Ciao, Michael.

Re: directory structure changed

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

On Fri, 28 Jul 2000, David Leonard typed thusly:

> > The build failed with:
> > ./linkedlist.c:106: `objobjproc' undeclared here (not in a function)
> oops, I've been building with Python 1.6a2 ..

i've committed a fix (i think). if it still breaks under 1.5 pls tell me.

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: directory structure changed

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

On Thu, 27 Jul 2000, Michael Ströder typed thusly:

> > finally moved everything around. I recommend using the -dP flags for 
> > cvs update when you next sync your trees.
> 
> I did a complete checkout and it seems that all the old dirs are
> still there. I'm not a CVS expert but "remove" should do it after
> deleting them in your local dir.

I tend to use 'cvs up -PAd' which deletes empty directories.. maybe there
are leftover non-cvs files in ldapmodule/ ? you have to remove those by hand.
or just 'rm -rf ldapmodule'.. :)

> I tried a build by going into python-ldap/python-ldap/ and typed
> "autoheader", "autoconf" and "configure --prefix=/usr".

there's also 'autoreconf' i remember now: it does autoheader and autoconf 
for you!

> The build failed with:
> gcc -fpic  -DLDAP_REFERRALS -O2 -m486 -I/usr/include/python1.5
> -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./linkedlist.c
> ./linkedlist.c:106: `objobjproc' undeclared here (not in a function)
> ./linkedlist.c:106: warning: excess elements in struct initializer
> ./linkedlist.c:106: warning: (near initialization for
> `default_methods')
> ./linkedlist.c:106: parse error before `0'
> make[1]: *** [linkedlist.o] Error 1
> make[1]: Leaving directory
> `/home/michael/temp/python-ldap/python-ldap/Modules'
> make: *** [all] Error 2

oops, I've been building with Python 1.6a2 ..

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Re: directory structure changed

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

David Leonard wrote:
> 
> finally moved everything around. I recommend using the -dP flags for 
> cvs update when you next sync your trees.

I did a complete checkout and it seems that all the old dirs are
still there. I'm not a CVS expert but "remove" should do it after
deleting them in your local dir.

I tried a build by going into python-ldap/python-ldap/ and typed
"autoheader", "autoconf" and "configure --prefix=/usr".

The build failed with:

gcc -fpic  -DLDAP_REFERRALS -O2 -m486 -I/usr/include/python1.5
-I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./linkedlist.c
./linkedlist.c:106: `objobjproc' undeclared here (not in a function)
./linkedlist.c:106: warning: excess elements in struct initializer
./linkedlist.c:106: warning: (near initialization for
`default_methods')
./linkedlist.c:106: parse error before `0'
make[1]: *** [linkedlist.o] Error 1
make[1]: Leaving directory
`/home/michael/temp/python-ldap/python-ldap/Modules'
make: *** [all] Error 2

Ciao, Michael.

directory structure changed

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

okay, 
finally moved everything around. I recommend using the -dP flags for cvs update
when you next sync your trees.

i stuck an ldap.py in Lib, but that will go when fog is ready to move 
ldaplib/ldap to Lib/ldap

also made a few misc changes to configure..

remember, you have to run autoheader before autoconf.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: Roadmap for ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered David Leonard's letter:

> > 5. LDAPObjects (low priority):
> > ------------------------------
> > We have to review Fog's work (hopefully I have the time!) to
> > establish a standard Pythonish, re-usable and robust class library
> > for LDAP applications.
> 
> i would like see a more general X.500 directory class and have 
> objectClasses more tightly coupled with python classes. that would be cool.
> it might also be cool to wrap LDAP as a db

give a look at .../ldaplib/ldap/schema. you'll find objectClasses and
attributes encapsulated as python classes. they do nothing at now but
the code in schema is already able to ask a v3 compatible server and
build the full classes/attributes/syntaxes tree.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
  99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me

Re: Roadmap for ldapmodule

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

On Thu, 27 Jul 2000, Michael Ströder typed thusly:

> > i think using Python's own source tree structure as
> > a basis would be  best.
> Ack. Looks reasonable. Let's do it!

ok. (any objections from anyone else?)

> Ok, what about the rest of the roadmap?



> 1. Module names (high priority):
> --------------------------------
> Please, rename _ldap back to ldap and rename Fog's stuff to

no, the ldap.py wrapper lib is sufficient.

> 2. CVS (high priority):
> -----------------------
discussed already

> 3. Release of C-module (high priority):
> ---------------------------------------
> AS SOON AS POSSIBLE
agreed! (after 2)

> 4. SSL (medium priority):
> -------------------------
> it's worth looking at OpenLDAP 2.0's new API because this will be
> the new standard API for LDAP.

you are right.  but I feel like waiting until OpenLDAP 2.0 is actually 
released. 
if existing netscape libs have ldap (i think i started downloading it 
yesterday.. but to where?) then that should certainly be supported

> 5. LDAPObjects (low priority):
> ------------------------------
> We have to review Fog's work (hopefully I have the time!) to
> establish a standard Pythonish, re-usable and robust class library
> for LDAP applications.

i would like see a more general X.500 directory class and have 
objectClasses more tightly coupled with python classes. that would be cool.
it might also be cool to wrap LDAP as a db

> 6. Distributing with Python's standard lib (low priority):
> ----------------------------------------------------------
not likely

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo