LDAP issues (and some fixes)

[Thomas LeRoux <lerouxt iname com>]

Hey all.. I just started using Balsa, and am very impressed with what's
been done so far!  I was looking for a package that would integrate well
with LDAP, and be full-featured enough to use on a day-to-day basis, and
Balsa seems to be the ticket!

Anyway, although LDAP is now working for me, it was a bit of a struggle to
compile, as well as use.  Here's what I've found so far..

COMPILATION PROBLEMS: First off, I'm using OpenLDAP 2.0.7, and it seems as
if the Balsa configuration script does not include libresolv.so (-lresolv)
when compiling its LDAP test program.  Not sure why, but I'm guessing this
is a new requirement for OpenLDAP.  Regardless, this is a pretty easy fix
to the configure.in, and I've included it in my patch attached.

DISPLAY NAME PROBLEMS: Once compiled, the Address book worked fairly well
when querying my LDAP directory.  However, once I selected a name from the
list, the display name on the email only shows "Lastname <foobar@host.com>"
instead of "Firstname Lastname <foobar@host.com>".  I took a quick look,
and it seems as if Balsa is not using the "cn" (Common Name) attribute for
the display name.  It's using the "sn" (Surname) and "givenName" (First
name) attributes concatenated.  However, since "cn" is a required
attribute, and since it was always intended to be the first name, I feel
this attribute is more correct (since I don't even use the "givenName"
attribute, I was only getting last names).  I think someone else was having
this problem as seen in the list archives.  This fix is included in the
patch attached.  I believe this also resolves bug # 29254.

CACHE PROBLEMS: Ahhggg!!!  This one drove me NUTS until I (sortof) figured
it out.  Here are the symptoms:  I go into the address book ("b"), all is
well, close it, and reopen it.  Balsa hangs forever.  I traced this to the
LDAP cache.  If the client LDAP cache is NOT enabled (by removing a couple
lines of code), then subsequent queries work fine.  This is obviously not
ideal since client caching is a good thing.  When I gdb at the point Balsa
freezes, it looks like we're hung up in a select() - waiting on the return
value from the LDAP pipe.  However, the server shows that a query never
arrived, so the client waits forever.  I THINK that since all entries are
retrieved from the cache, the LDAP libraries incorrectly wait for data to
return from a query that never occured.  This is obviously an OpenLDAP
problem, but before I bring it to the OpenLDAP folks, has anyone else been
able to duplicate this?  This may also be solved by Balsa implemented
ldap_search instead of ldap_search_s.  This is probably a better design
anyway, as any LDAP delays will not affect the app thread.  That is, a 60
second LDAP query won't freeze the app.  Regardless, I've commented out the
client side cache in my patch - feel free to ignore this change.

-Tom

balsa.patch