python-ldap-dev — discussion among developers

Re: python-ldap-2.0

[Sascha G. <sa...@fr...>]

[...]
> > 
> > So implementing all in pure python isnt the way to go ?.
> 
> A pure Python implementation would be hard work!

I agree ;-)

> 
> Did you release some of your LDAP-related SWIG stuff to the public?

Yes, have a look at http://www.free.de/homes/sascha/swig-ldap.

> Maybe I missed the announcement. 

Well using swig-ldap might still be awfull for users of python-ldap,
so I wasnt talking to much about it ...

>Since python-ldap 2.0 is meant to
> be a completely new implementation you're welcome to contribute your
> work with SWIG.
> 

Maybe its not as complete as python-ldap but its used in a productive
enviroment (solaris 5.5.1 / 7.2 ; freebsd ) and might serve as an
interesting
example.

Bye,

	Sascha


> Ciao, Michael.
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev
> 
-- 
/* Yeah  */

Re: python-ldap-2.0

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

Sascha Gresk wrote:
> 
> > > to provide an abstraction of the LDAP C API.)
> 
> So implementing all in pure python isnt the way to go ?.

A pure Python implementation would be hard work!

I played with an ASN.1 decoder/encoder module for a while. Even
building the messages is not easy but think of all the schema
handling and syntax checking - not to speak of SSL/TLS ...

> > > Please, comment!
> 
> So are you still going to handcraft all wrappers by hand ? - I
> am still using SWIG to get this job done for my environment.
> Now I have a job to swig myself towards v3 ...

Did you release some of your LDAP-related SWIG stuff to the public?
Maybe I missed the announcement. Since python-ldap 2.0 is meant to
be a completely new implementation you're welcome to contribute your
work with SWIG.

Ciao, Michael.

Re: python-ldap-2.0

[Sascha G. <sa...@fr...>]

> > In addition, I seek more comment on any more changes that the _ldap
> library
> > may need to support LDAPv3 connections. (Remember that the purpose of
> this
> > module is not to give an abstraction of X.500 directory services, but
> rather
> > to provide an abstraction of the LDAP C API.)

So implementing all in pure python isnt the way to go ?.

> > Please, comment! 

So are you still going to handcraft all wrappers by hand ? - I
am still using SWIG to get this job done for my environment.
Now I have a job to swig myself towards v3 ...

> 
> Yes! I hope this discussion is not "local". ;-)
> 

Well, Dortmund and Karlsruhe might be considered local ;-)

> Ciao, Michael.
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev
> 
-- 
/* Yeah  */

Re: python-ldap-2.0

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

David Leonard wrote:
> 
> On Sun, 10 Dec 2000, Michael Ströder typed thusly:
> > I think we should leave the 1.x stuff as is and start with
> > python-ldap-ext based on OpenLDAP 2.0.x...
> 
> Okay, to keep everyone on the list informed:
> 
> Michael, as a knowledgable Karlsruhe local, showed me all the local
> restaurants that have closed down and then we discussed the direction for
> python-ldap. After a few drinks, and a discussion on cats, we agreed on
> the following plan:

Been there, got a t-shirt(?).

> In addition, I seek more comment on any more changes that the _ldap library
> may need to support LDAPv3 connections. (Remember that the purpose of this
> module is not to give an abstraction of X.500 directory services, but rather
> to provide an abstraction of the LDAP C API.)

I would like to stay as close as possible to the new LDAP-EXT API in
OpenLDAP 2.0.x since this API already trys to give some level of
abstraction (SASL for providing several authentication methods
etc.).

Once again the things I would like to see:

- LDAPv3 binding
- proper support for search continuations (LDAPv3 referrals)
- SSL and STARTTLS support
- Access to schema functions (would save lots of work in Python
applications)
- Virtual List Controls (rather low-prio)

IMHO python-ldap 2.0 should provide as much access to the C-API as
possible (except the functions marked as deprecated in ldap.h. We
can put a Python-written abstraction layer above this later.

> Please, comment! 

Yes! I hope this discussion is not "local". ;-)

Ciao, Michael.

python-ldap-2.0

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

On Sun, 10 Dec 2000, Michael Ströder typed thusly:
> I think we should leave the 1.x stuff as is and start with
> python-ldap-ext based on OpenLDAP 2.0.x...

Okay, to keep everyone on the list informed:

Michael, as a knowledgable Karlsruhe local, showed me all the local
restaurants that have closed down and then we discussed the direction for
python-ldap. After a few drinks, and a discussion on cats, we agreed on
the following plan:

	* python-ldap-1.10 will be tidied up, with just the memory-leak
	  patches applied, and a proper documentation build. (ie no v3
	  changes will be applied as it breaks v2 builds.) A final release
	  will be made.

	* A new python-ldap-2.0 will be started, with an API that is likely
	  to be somewhat incompatible with that of p-l-1.10. In particular,
	  the following will be the major compatibility targets:
		+ Python-2.0 support (ie unicode)
		+ OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT)

This means that people relying on v2 client/servers should be happy enough
with a reasonably stable release.  And people wanting to live in the 3rd
millenium should be happy with a version (relatively) free of legacy support.

Please, comment! Are there problems with the above plan?

In addition, I seek more comment on any more changes that the _ldap library
may need to support LDAPv3 connections. (Remember that the purpose of this
module is not to give an abstraction of X.500 directory services, but rather
to provide an abstraction of the LDAP C API.)

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

Re: on removing constants

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

David Leonard wrote:
> 
> Does anyone ever use them? Here's the list
> [..]
>         OPT_REFERRALS

I was using it.

> Does anyone even use the cache control stuff?

Yes.

I think we should leave the 1.x stuff as is and start with
python-ldap-ext based on OpenLDAP 2.0.x...

Ciao, Michael.

on removing constants

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

On Thu, 16 Nov 2000, Jeffrey C. Ollie typed thusly:

> I've gotten today's CVS version to compile against OpenLDAP 2.0.7.  It
> seems that the OpenLDAP people dropped a number of macros between v1
> and v2.  A fairly simple patch that #ifdefs the dropped macros and
> everything compiles fine.

I think it will be more beneficial to just remove those dead constants from
the python namespace altogether.

Does anyone ever use them? Here's the list

	MAX_ATTR_LEN
	REQ_UNBIND_30
	REQ_DELETE_30
	REQ_ABANDON_30
	AUTH_SIMPLE_30
	AUTH_KRBV41_30
	AUTH_KRBV42_30
	FILTER_PRESENT_30
	SUBSTRING_INITIAL_30
	SUBSTRING_ANY_30
	SUBSTRING_FINAL_30
	URL_ERR_NOTLDAP
	URL_ERR_NODN

	CACHE_BUCKETS
	CACHE_OPT_CACHENOERRS
	CACHE_OPT_CACHEALLERRS

	DEFAULT_REFHOPLIMIT
	OPT_DNS
	OPT_REFERRALS

Does anyone even use the cache control stuff?
If you do, I will suggest that the future cache calls be of the form
	l.set_cache_options("noerrs", "blah")
Instead of
	l.set_cache_options(_ldap.CACHE_OPT_CACHENOERRS | _ldap.BLAH)
It reads a bit easier too. comments?

What about the referrals and DNS options? someone must, surely :)
i think also that a string-base approach would be better there too.
	>>> l.options
	("restart",)
	>>> l.options = l.options + "referrals",
	>>> l.options
	("referrals", "restart")
	>>> l.options = l.options + "snork",	# silently ignored??
	("referrals", "restart")

i've been talking to michael stroeder about getting all these things
together in a clean way for a '2.0' release of python-ldap. this means
that strong changes like the above are quite possible.

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange


Index: constants.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/constants.c,v
retrieving revision 1.5
diff -u -r1.5 constants.c
--- constants.c	2000/08/13 15:00:59	1.5
+++ constants.c	2000/12/10 13:07:58
@@ -66,7 +66,7 @@
 	add_int(d,VERSION1);
 	add_int(d,VERSION2);
 	add_int(d,VERSION);
-	add_int(d,MAX_ATTR_LEN);
+	/* add_int(d,MAX_ATTR_LEN); */
 	add_int(d,TAG_MESSAGE);
 	add_int(d,TAG_MSGID);

@@ -79,9 +79,9 @@
 	add_int(d,REQ_MODRDN);
 	add_int(d,REQ_COMPARE);
 	add_int(d,REQ_ABANDON);
-	add_int(d,REQ_UNBIND_30);
-	add_int(d,REQ_DELETE_30);
-	add_int(d,REQ_ABANDON_30);
+	/* add_int(d,REQ_UNBIND_30); */
+	/* add_int(d,REQ_DELETE_30); */
+	/* add_int(d,REQ_ABANDON_30); */

 	/* reversibles */

@@ -106,9 +106,9 @@
 	add_int(d,AUTH_KRBV4);
 	add_int(d,AUTH_KRBV41);
 	add_int(d,AUTH_KRBV42);
-	add_int(d,AUTH_SIMPLE_30);
-	add_int(d,AUTH_KRBV41_30);
-	add_int(d,AUTH_KRBV42_30);
+	/* add_int(d,AUTH_SIMPLE_30); */
+	/* add_int(d,AUTH_KRBV41_30); */
+	/* add_int(d,AUTH_KRBV42_30); */
 	add_int(d,FILTER_AND);
 	add_int(d,FILTER_OR);
 	add_int(d,FILTER_NOT);
@@ -118,13 +118,13 @@
 	add_int(d,FILTER_LE);
 	add_int(d,FILTER_PRESENT);
 	add_int(d,FILTER_APPROX);
-	add_int(d,FILTER_PRESENT_30);
+	/* add_int(d,FILTER_PRESENT_30); */
 	add_int(d,SUBSTRING_INITIAL);
 	add_int(d,SUBSTRING_ANY);
 	add_int(d,SUBSTRING_FINAL);
-	add_int(d,SUBSTRING_INITIAL_30);
-	add_int(d,SUBSTRING_ANY_30);
-	add_int(d,SUBSTRING_FINAL_30);
+	/* add_int(d,SUBSTRING_INITIAL_30); */
+	/* add_int(d,SUBSTRING_ANY_30); */
+	/* add_int(d,SUBSTRING_FINAL_30); */
 	add_int(d,SCOPE_BASE);
 	add_int(d,SCOPE_ONELEVEL);
 	add_int(d,SCOPE_SUBTREE);
@@ -135,34 +135,24 @@

 	/* (errors.c contains the error constants) */

-	add_int(d,DEFAULT_REFHOPLIMIT);
-#ifdef LDAP_CACHE_BUCKETS
-	add_int(d,CACHE_BUCKETS);
-#endif
-#ifdef LDAP_CACHE_OPT_CACHENOERRS
-	add_int(d,CACHE_OPT_CACHENOERRS);
-#endif
-#ifdef LDAP_CACHE_OPT_CACHEALLERRS
-	add_int(d,CACHE_OPT_CACHEALLERRS);
-#endif
+	/* add_int(d,DEFAULT_REFHOPLIMIT); */
+	/* add_int(d,CACHE_BUCKETS); */
+	/* add_int(d,CACHE_OPT_CACHENOERRS); */
+	/* add_int(d,CACHE_OPT_CACHEALLERRS); */
 	add_int(d,FILT_MAXSIZ);
 	add_int(d,DEREF_NEVER);
 	add_int(d,DEREF_SEARCHING);
 	add_int(d,DEREF_FINDING);
 	add_int(d,DEREF_ALWAYS);
 	add_int(d,NO_LIMIT);
-#ifdef LDAP_OPT_DNS
-	add_int(d,OPT_DNS);
-#endif
-#ifdef LDAP_OPT_REFERRALS
-	add_int(d,OPT_REFERRALS);
-#endif
+	/* add_int(d,OPT_DNS); */
+	/* add_int(d,OPT_REFERRALS); */
 	add_int(d,OPT_RESTART);

 	/* XXX - these belong in errors.c */

-	add_int(d,URL_ERR_NOTLDAP);
-	add_int(d,URL_ERR_NODN);
+	/* add_int(d,URL_ERR_NOTLDAP); */
+	/* add_int(d,URL_ERR_NODN); */
 	add_int(d,URL_ERR_BADSCOPE);
 	add_int(d,URL_ERR_MEM);

"Couldn't find LDAP library" error on configure

[J B B. <ci...@re...>]

Hello, I'm getting this error on builds with the same source files on 
different operating systems, to with:

Solaris 2.7 and Debian GNU/Linux 2.2r1 (kernel is 2.2.17)
Both openldap-2.0.7 and openldap-1.2.11

Even with --with-ldap-lib and --with-ldap-inc set appropriately, I am still
getting:

checking for ldap_open... no
configure: error: Couldn't find LDAP library
  Please specify the location of the LDAP library using either --with-ldap=DIR, 
  --with-ldap-lib=PATH/lib, or --with-ldap-inc=PATH/include options.  You
  may also need to specify where the Kerberos libraries are if the LDAP
  library needs to be linked against that.

The suggested openldap.sh script fails, even with editing to fix the out-
dated filenames, I think because I am behind a firewall (ftplib, for example,
only works if I do a set_pasv(1)).

I'm hoping this is something obvious, and tried searching the archive, but
didn't find anything.  Please forgive this humble supplicant's ignorance
and help to light his way.  I am just starting with python and rather dig
it, so I hope to get this going to move on to bigger & better things.

--JB
Redback Networks

documentation

[Andrew C. <And...@it...>]

hi there

i hope this is not deemed to be to trivial for an answer....

is there some difference b/w the format of the tex in the documentation
and normal tex? when i try 
tex python-ldap-1.10alpha3/Doc/_ldap/Doc.tex

i get 
! Undefined control sequence.
messages

is there something else i need to read the documentation for this
project?  
lines like the following are a hard hard to cope with for a new to
python person

\begin{methoddesc}[int]{search}{base\, scope\, filter\optional{\,
        attrlist=\constant{None}\optional{\, attrsonly=\constant{0}}}}
     \methodline[list|None]{search_s}{base\, scope\, filter\optional{\,
        attrlist=\constant{None}\optional{\, attrsonly=\constant{0}}}}
    \methodline[list|None]{search_st}{base\, scope\, filter\optional{\,
        attrlist=\constant{None}\optional{\, attrsonly=\constant{0}
        \optional{\, timeout=\constant{-1}}}}}


cheers
-- 
Andrew Creer
Portal Programmer, Flexible Learning and Teaching
Information Technology Services, Monash University - Clayton
Phone: +61 3 990 55830       Fax: +61 3 990 53024

web2ldap 0.8.0

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

HI!

There's a new release of web2ldap available at:

  http://www.web2ldap.de/download.html

Summary of changes since 0.7.10:
Displays X.509 certs and CRLs including extensions, basic LDAPv3
referral handling, smarter exception handling for LDAP errors, needs
Python 2.0 (Unicode handling) and recent python-ldap module, several
small configuration changes, some changes in UI, bug fixes.

Ciao, Michael.

New python-ldap-1.10alpha3 RPM available w/ OpenLDAP 2.x patch

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

I've place on Open-IT.org's website my first build of python-ldap w/ the
patch provided by Jeffrey C. Ollie on this list. If there is anything
you'd like better with the RPM, as well as who I need to site, etc, please
tell me. There were no SRPMs available to build from, so this is a new RPM
spec file and all that.. 

http://www.open-it.org/download

The file is both in the prototypes directory (with my addluser script),
and in each of the distribution directories. SRPMS are with the
distributions only.

You can track any changes to the RPM via www.open-it.org

Re: Autoconf problem [Was: patch to compile with OpenLDAP 2.0.7]

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

if i recall correctly, just run 'automake'. it runs autoheader and autoconf
in the right order. you should run it just before building a release too.

On Wed, 22 Nov 2000, Konstantin Chuguev typed thusly:
> > I discovered that my config.h File ist empty.
> The problem has been here since I started using CVS version, i.e. a month ago.
> My auto* stuff ignores python-ldap/acconfig.h file for some reason and tries to
> produce python-ldap/Modules/config.h file from the corresponding config.h.in
> file, which is missing in CVS. Fortunately I kept the latest release version
> and I got the missing file from there. I'm attaching the file just in case. You

config.h.in is generated by autoheader. its all so... automatic!!

> need to do make distclean and ./configure ... again.
> After that you will get a correct config.h file.
> I know this is not a good way of fixing the problem, but I didn't have time to
> do it properly.
> Or maybe that's just my mistake.
> Can anybody tell me in which order I shall apply autoconf commands before doing
> ./configure?

-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Autoconf problem [Was: patch to compile with OpenLDAP 2.0.7]

[Konstantin C. <Kon...@da...>]

Burkhard Noltensmeier wrote:

> Hallo,
>
> Thank you for your patches. I was able to apply them cleanly
> I apologise for disturbing you another one time.
> When i compile the hole stuff I get an error message.
> Unfortunately i do not really understand what the Problem is.
> I discovered that my config.h File ist empty.
> Maybe the configure Script guessed the LDAP type in a wrong way.
> I am using Redhat-7.0 with Openldap-2.07
>

Yes, I had the same problem, but I thought it was because of my slightly
screwed up Solaris autoconf/automake environment. It appears not only Solaris
thing...
The problem has been here since I started using CVS version, i.e. a month ago.
My auto* stuff ignores python-ldap/acconfig.h file for some reason and tries to
produce python-ldap/Modules/config.h file from the corresponding config.h.in
file, which is missing in CVS. Fortunately I kept the latest release version
and I got the missing file from there. I'm attaching the file just in case. You
need to do make distclean and ./configure ... again.
After that you will get a correct config.h file.
I know this is not a good way of fixing the problem, but I didn't have time to
do it properly.
Or maybe that's just my mistake.
Can anybody tell me in which order I shall apply autoconf commands before doing
./configure?

Thanks,
    Konstantin.

>
> This is the Compile Error:
>
> [root@bn python-ldap]# make
> cd Modules && make srcdir=/home/burkhard/ldap/python-ldap/Modules
> VPATH=/home/bu
> rkhard/ldap/python-ldap/Modules
> make[1]: Wechsel in das Verzeichnis
> Verzeichnis ?/hda4/burkhard/ldap/python-ldap
> /Modules?
> gcc -fPIC  -I. -DLDAP_REFERRALS -I/tmp/ldap-pfx/include -g -O2 -I/usr/includ
> e/py
> thon1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c
> /home/burkhard/ldap/python-l
> dap/Modules/LDAPObject.c
> /home/burkhard/ldap/python-ldap/Modules/LDAPObject.c: In function
> `l_ldap_set_re
> bind_proc':
> /home/burkhard/ldap/python-ldap/Modules/LDAPObject.c:617: warning: passing
> arg 2
>  of `ldap_set_rebind_proc' from incompatible pointer type
> /home/burkhard/ldap/python-ldap/Modules/LDAPObject.c: In function
> `l_ldap_modrdn
> ':
> /home/burkhard/ldap/python-ldap/Modules/LDAPObject.c:1142: too many
> arguments to
>  function `ldap_modrdn'
> ......
>
> Burkhard Noltenmsieer

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

web2ldap 0.8.0pre4

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

HI!

There's a new snapshot of web2ldap available at:

  http://www.web2ldap.de/download.html

Consider this pre-release to be experimental. Please check out the
changes list to see which things are fixed and which things needs to
be tested thoroughly.

Changes since 0.8.0pre3:
- Added module pisces.asn1 to package.
- Slightly updated docs.

Ciao, Michael.

Win32 build

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

HI!

Does anybody provide Win32 builds of python-ldap?

Ciao, Michael.

Unicode objects

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

HI!

BTW: Unicode objects (Python 1.6+) are quite handy for LDAP
applications which have to hande NON-ASCII characters...

Ciao, Michael.

Re: thoughts on v3 support

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

David Leonard wrote:
> 
> 1) it is possible to ditch all c library support and implement ldap
> client code in 100% pure python. the problem is that this is WAY too
> much effort

I already seriously thought about this. I'm currently using a ASN.1
parser module written by Jeremy Hylton for my own X.509 certificate
library. I'm doing some patches for this to get more standard ASN.1
types into it.

This ASN.1 module could be used to implement a LDAP library. I agree
it's much effort.

> 2) alternatively, python-ldap could be 'bundled' with a 'preferred' ldapv3
> implementation. main problem here is that of choosing one preferred impl
> bearing in mind that users will find very good reasons to use other libs

As I already said: You will have difficulties to download the right
version of at least the Netscape libs (not sure about the Novell
libs). Recent Netscape version 4.x differ is various aspects like
setting options etc. that it will be difficult to support them.

> 3) of course, i think that the real answer is to get a new 'standard' api

YES!

> that the various ldapv3 libs are expected to adhere to, then concentrate
> on that (with possible support for particular library extensions. )

YES!

Concentrating on the OpenLDAP 2.0.x libs would give access to more
useful features besides LDAPv3 binding like:
- LDAP over SSL
- LDAP with STARTTLS
- SASL
- normalizing functions for DNs
- UTF-8 checking
- all schema stuff
- LDAP syntax checking
...

> i couldn't find an LDAPv3 rfc that could be used as for specifying the api.
> RFC1823 is way out of date now. on the other hand, there is the Java API
> for ldapv3...

There's no RFC yet. OpenLDAP 2.0.x implements LDAPEXT-API which is
only an Internet draft up to now. See
http://www.ietf.org/html.charters/ldapext-charter.html for more
info.

Ciao, Michael.

thoughts on v3 support

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

On Fri, 17 Nov 2000, Jeffrey C. Ollie typed thusly:
> > Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable
> > stable there's no good reason anymore to support outdated APIs. (In
> > the case of Netscape and Novell you even can't download them
> > anymore.)
> I don't know about Netscape, but you can certainly download the Novell
> LDAP libraries.  However, that's orthoginal as to whether we want to
> keep support for other libraries.

some thoughts

1) it is possible to ditch all c library support and implement ldap
client code in 100% pure python. the problem is that this is WAY too
much effort

2) alternatively, python-ldap could be 'bundled' with a 'preferred' ldapv3
implementation. main problem here is that of choosing one preferred impl
bearing in mind that users will find very good reasons to use other libs

3) of course, i think that the real answer is to get a new 'standard' api
that the various ldapv3 libs are expected to adhere to, then concentrate
on that (with possible support for particular library extensions. )

i couldn't find an LDAPv3 rfc that could be used as for specifying the api.
RFC1823 is way out of date now. on the other hand, there is the Java API
for ldapv3...

does anyone know if the v3 libs that are coming out adhere to some
written-down standard api?  should someone here just declare one and
write it down?

comments?

d

PS met up with michael stroder and mirko in Karlsruhe last night.
apart from feeding me concoctions of banana and cherry juice, they tried
to teach me some german.
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Re: patch to compile with OpenLDAP 2.0.7

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

"Jeffrey C. Ollie" wrote:
> 
> Yes, a worthy goal.  However, it'd be nice to get a version out the
> door that compiles/links against 2.0.x and then worry about new
> functionality introduced by LDAPv3.

Konstantin's patches already compile cleanly and work. I will do
further testing this weekend. The most important goal was to be able
to bind as a LDAPv3 client.

> SSL/TLS would be high on my priority list.  I do know how to program
> in C but programming isn't my primary duty at work and I don't ever
> seem to get much free time at home that I can work on programming.

One of the main advantages of the OpenLDAP 2.0.x libs is that they
have already built-in support for LDAP over SSL, LDAP with STARTTLS
extension and SASL binding. Theoretically you can enable features
this by setting the right options...

Ciao, Michael.

Re: patch to compile with OpenLDAP 2.0.7

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

On Fri, Nov 17, 2000 at 07:51:10PM +0100, Michael Str=F6der wrote:
> Konstantin Chuguev wrote:
> >
> > I didn't touch anything related to Netscape/Mozilla/Umich SDK in my
> > patches.
>=20
> Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable
> stable there's no good reason anymore to support outdated APIs. (In
> the case of Netscape and Novell you even can't download them
> anymore.)

I don't know about Netscape, but you can certainly download the Novell
LDAP libraries.  However, that's orthoginal as to whether we want to
keep support for other libraries.

Re: patch to compile with OpenLDAP 2.0.7

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

On Fri, Nov 17, 2000 at 07:48:18AM +0100, Michael Str=F6der wrote:
> "Jeffrey C. Ollie" wrote:
> >=20
> > I didn't know that anyone else was working on it...  The list has been
> > quiet for some time now.
>=20
> We did not expect anybody else to work on it. Therefore there was no
> announcement here.
>=20
> > It looks like Konstantin's work goes beyond what I intended to
> > accomplish.  I wasn't looking to add any functionality, just to
> > get python-ldap to compile and work.
>=20
> Well, when building against OpenLDAP 2.0.x libs you gain some new
> important features. Especially LDAPv3 is what we basically need to
> handle referrals in a reasonable manner. This might lead to
> incompatible python-ldap API but the new features are worth it, I
> think.

Yes, a worthy goal.  However, it'd be nice to get a version out the
door that compiles/links against 2.0.x and then worry about new
functionality introduced by LDAPv3.

> >  But I'd be happy to test out other patches and perhaps fix a bug
> > or two.
>
> Well, are you interested in adding new functionality? If yes,
> SSL/TLS support and some parts of the new LDAPEXT-API would be nice.
> I'm not a C programmer myself. I can just provide help with
> designing the new API and doing extensive tests.

SSL/TLS would be high on my priority list.  I do know how to program
in C but programming isn't my primary duty at work and I don't ever
seem to get much free time at home that I can work on programming.

But who knows, maybe I'll stay up late one night...

Jeff

Re: patch to compile with OpenLDAP 2.0.7

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

Konstantin Chuguev wrote:
> 
> Knowing which features are supported is useful though. But it doesn't
> necessarily have to be done by creating constants in python-ldap which values
> are set at the compilation time. For example, if you try to set the version
> attribute to any value in python-ldap compiled against OpenLDAPv1.2, you'll get
> an exception; same case with using ufn_ methods etc.

Yes, an exception is sufficient.

Well, let me repeat my position: You can change python-ldap to be
completely incompatible to previous versions. I'm fine with that if
I get full LDAPv3 support (some steps already made by Konstantin
:-), VLV, SSL/TLS, bla di bla...

> I didn't touch anything related to Netscape/Mozilla/Umich SDK in my
> patches.

Drop it. Since OpenLDAP 2.0.x is out and seems to be reasonable
stable there's no good reason anymore to support outdated APIs. (In
the case of Netscape and Novell you even can't download them
anymore.)

> Maybe we should consider extending LDAPerror function somehow...

Anyway, drop compability whereever it's necessary to have a cleaner
design! I'm fine with a new CVS branch for python-ldap.

For compability with old python-ldap we can write a Python wrapper
class later...

Ciao, Michael.

Re: patch to compile with OpenLDAP 2.0.7

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

David Leonard wrote:
> 
> i have a medium concern, something that i've been guilty of and would like 
> to see go away, and that is conditional existance of interfaces.
> 
> eg  ufn_search_s() might be #ifdef'd out and some python program that wants
> to use it will get a NameError when it tries to use it. A better exception
> would be NotImplementedError.

Kick it out. Even the exception you mentioned isn't necessary. No
serious LDAP programmer used it I guess.

> A similar problem arises with 'constants'.. I'm not sure what to do here..
> make all undefined cosntants equal None?

Just kick it out.

> also there should be some nice way of reliably determining the
> underlying library's api version ... maybe _ldap.api_version...
> any suggestions on how that might be done nicely are welcome.

I even have no problems with starting from scratch. I happily
rewrite the changed parts in web2ldap just to get proper LDAPv3
support and SSL/TLS...

Maybe let's start with a new LDAPEXT-inspired python-ldap 2.x?

Ciao, Michael.

Re: patch to compile with OpenLDAP 2.0.7

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

"Jeffrey C. Ollie" wrote:
> 
> On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Ströder wrote:
> > "Jeffrey C. Ollie" wrote:
> > >
> > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7.
> >
> > Ooops. Double efforts. I'm currently testing patches by Konstantin
> > (Cc:-ed) which also allow to retrieve search continuation references
> > (LDAPv3 referrals).
> >
> > He made some changes to attributes of LDAPObject. Especially setting
> > the options is different.
> 
> I didn't know that anyone else was working on it...  The list has been
> quiet for some time now.

We did not expect anybody else to work on it. Therefore there was no
announcement here.

>  It looks like Konstantin's work goes beyond
> what I intended to accomplish.  I wasn't looking to add any
> functionality, just to get python-ldap to compile and work.

Well, when building against OpenLDAP 2.0.x libs you gain some new
important features. Especially LDAPv3 is what we basically need to
handle referrals in a reasonable manner. This might lead to
incompatible python-ldap API but the new features are worth it, I
think.

>  But I'd
> be happy to test out other patches and perhaps fix a bug or two.

Well, are you interested in adding new functionality? If yes,
SSL/TLS support and some parts of the new LDAPEXT-API would be nice.
I'm not a C programmer myself. I can just provide help with
designing the new API and doing extensive tests.

Ciao, Michael.

Re: patch to compile with OpenLDAP 2.0.7

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

On Fri, Nov 17, 2000 at 03:34:54PM +0100, David Leonard wrote:
>=20
> eg  ufn_search_s() might be #ifdef'd out and some python program that wan=
ts
> to use it will get a NameError when it tries to use it. A better exception
> would be NotImplementedError.

I don't have a huge problem with that.

> A similar problem arises with 'constants'.. I'm not sure what to do here..
> make all undefined cosntants equal None?

No, as this will cause problems that are harder to debug as None may
be a valid parameter in some cases.  If you let NameError exceptions
be raised you can immediately track down the offending reference.  I
don't think that adding code to raise NotImplementedError in the case
of undefined constants buys you anything but code bloat.

> also there should be some nice way of reliably determining the
> underlying library's api version ... maybe _ldap.api_version...
> any suggestions on how that might be done nicely are welcome.

I'd suggest using LDAP_API_VERSION, LDAP_VENDOR_NAME, and
LDAP_VENDOR_VERSION.  There are also some miscellaneous
LDAP_API_FEATURE* macros.

Jeff

P.S. Konstantin: I didn't receive a copy of your e-mail with the
patches, could you try sending it again?