patch to compile with OpenLDAP 2.0.7

[Konstantin Chuguev]

"Jeffrey C. Ollie" wrote:

> On Fri, Nov 17, 2000 at 03:34:54PM +0100, David Leonard wrote:
> >
> > 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.
>
> I don't have a huge problem with that.
>

Neither do I.

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

I would agree with Jeffrey here.

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

I think David is talking about determining an API version in Python. IMO, as all
the python LDAP calls and methods go through the python-ldap anyway, there is a
little reason to uncover C API implementation details to the python level.
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.
I mean, python-ldap should try to hide as many libldap implementation details
from the python level as possible, and if it cannot, to indicate it in the most
native (Python-wise) way of failure (such as exception).
As for C LDAP macros indicating vendor, version and supported features, I don't
know much about them. I used approach suggested by Kurt Zeilenga in the attached
message. I didn't touch anything related to Netscape/Mozilla/Umich SDK in my
patches.

There is one thing I don't like in the patches. A client may need ldap.REFERRAL
exception to return a list of referral URLs, along with the standard LDAP
exception information. Currently, I see no way to attach a variable to the
exception object dictionary, as LDAPerror function does not have enough
arguments for that. What I have done on the patches is a hack, imitating LDAPv2
behaviour. Maybe we should consider extending LDAPerror function somehow...

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

Sure, I'll send them directly to you in the next message. Not sure if it'll get
through, because the original message failed with the following error:
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. The following address(es) failed:

  jeff at ollie.clive.ia.us:
    SMTP error from remote mailer after RCPT TO:<jeff at ollie.clive.ia.us>:
    host max.ollie.clive.ia.us [161.210.214.102]:
    550 Cannot route to <jeff at ollie.clive.ia.us>

Regards,
    Konstantin.

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


-------------- next part --------------
An embedded message was scrubbed...
From: "Kurt D. Zeilenga" <Kurt at OpenLDAP.org>
Subject: Re: How to check OpenLDAP version?
Date: Fri, 03 Nov 2000 17:13:42 -0800
Size: 1742
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20001117/545aaa35/attachment.mht>