apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] LDAP support for apr-util
Date Wed, 01 Aug 2001 07:14:18 GMT
On Tue, Jul 31, 2001 at 11:10:41AM +0200, Graham Leggett wrote:
> Would APR_ADDTO replace APR_CHECK_LIB? I just used macros that are
> available as part of Autoconf - I am not familiar with any of the APR
> macros.

This line:
    LIBS="-l${ldaplib} ${extralib} $LIBS"
would be replaced with:
    APR_ADDTO(LIBS, "-l${ldaplib} ${extralib}")
m4 escaping rules may want it to be (I forget):
    APR_ADDTO(LIBS, [-l\${ldaplib} \${extralib}])

AC_CHECK_LIB stays the same.  This just prevents multiple instances of
the same library from being inserted into the LIBS string (which is a
real annoyance).

> > You will also need to add the -R flags for Solaris (not sure the best
> > way to do this - be nice if APR had a macro like APR_ADDLIB which also
> > added the -R flag when needed).
> What does the -R flag do, and how should it be added?

On Solaris, -R specifies "add this directory to the run-time linker 
search path."  GNU ld has -rpath.  This obviates the need for
LD_LIBRARY_PATH and other hacks.  Wherever you do -L, you should add -R
(only if you are on Solaris).  I'd also do -rpath on Linux, but that's

APR_ADDTO(LDFLAGS, "-L/path/to/lib")
if on Solaris, you also want to do: APR_ADDTO(LDFLAGS, "-R/path/to/lib")
if on Linux, you also want to do: APR_ADDTO(LDFLAGS, "-Wl,-rpath /path/to/lib")

> > > /* LDAP header files */
> > > #if APR_HAVE_LDAP_H
> > > #include <@with_ldap_include@ldap.h>
> > > #endif
> > > #if APR_HAVE_LBER_H
> > > #include <@with_ldap_include@lber.h>
> > > #endif
> > > #include <@with_ldap_include@ldap_ssl.h>
> > > #endif
> > 
> > Couldn't we rely on setting CFLAGS/CPPFLAGS correctly instead?
> Do you have an example of how to do this?

If you set the CFLAGS and CPPFLAGS environment variables in your
autoconf script, those directories should be included in the Makefile
when you build.  Therefore, the path in the #include directive is moot.

> The idea behind it is that various lookup and compare operations are
> cached, rather than the results of actual LDAP queries. It has a large
> performance advantage, as often repeated queries (is this
> username/password correct, is this dn a member of this group) are not
> repeated on every hit.

In my experience, LDAP code should be fairly fast.  It really doesn't
even depend on your LDAP server.  I run OpenLDAP on a SparcStation 10 - 
that's not much fun (40MHz CPUs), but the lookups and queries are 
really quick.  On current hardware, this is really a non-issue.

> > If you really want to cache it locally, I'd use anonymous DBMs or
> > something more abstract (i.e. not at this level, but at the level
> > where this code would be called).  I'm not sold on needing to have
> > this cache in the general case.
> I'd like to review this cache stuff down the line - as it currently uses
> malloc() and free(). Either a DBM based or SMS based cache might do the
> trick.
> In the meantime, I am busy trying to hide the cache entirely from the
> caller so we can fiddle on the backend without breaking things.

Yeah, get it in and then let's see if we can remove the need for
caching.  My gut tells me that you won't really want it.  I could be
wrong though.

> > For reliability reasons, you probably want to use asynchronous bindings.
> > 
> > Do:
> > ldap_init
> > ldap_simple_bind
> > ldap_result
> > 
> > If the LDAP server is unreachable, you'll block waiting for the server
> > to respond.  It's really preferable to use asynchronous bindings (I've
> > used 1 second timeouts in the past).
> Hmmm - this is better, yes. Will change this.
> How would this impact locking?


I'd have the API in apr-util be essentially blocking, but the 
underlying implementation may use asynchronous with timeouts.  The 
user of apr-util shouldn't have to deal with the asynchronous crap
(as far as he knows, it is synchronous).  -- justin

View raw message