<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 8/13/2012 8:24 AM, Mark Banner
wrote:<br>
</div>
<blockquote cite="mid:50290012.2040200@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
There's two possible routes I think we could go down:<br>
<ol>
<li>Replace the sdk with the OpenLDAP version, I believe this
would need some API tweaks and obviously testing to ensure no
functional difference, or<br>
</li>
<li>Replace the sdk with a javascript version, which would
obviously need some rewriting.</li>
</ol>
</blockquote>
<br>
It's been a few months with no one other than me interjecting in
this thread (am I really the only other person who has opinions on
LDAP code?), so I thought I'd try investigating consequences of
switching to OpenLDAP. The following is a list of potential issues
that I could come up with and my investigative results:<br>
<br>
1. License compatibility.<br>
OpenLDAP's license is essentially equivalent to three-clause BSD,
so there's no incompatibility there.<br>
2. Ability to use NSPR/NSS as underlying base library.<br>
There is a configure option to use nss, --withtls=moznss.
Compiling with this flag and pointing to libraries in Thunderbird's
dist directory worked, but careful investigation of build ordering
leads me to believe that platform configure happens too early (it
looks for the nssutil.h include header, which doesn't happen in the
right place). Tweaking the -I paths may help here. But, given a
completed Thunderbird build, the program built correctly, and I
verified via ldd that all of the library dependencies were their
proper NSS/NSPR equivalents.<br>
3. Size.<br>
OpenLDAP, as measured by the unpacked version of
openldap-2.4.33.tgz, is 27MB of disk space. ldap/sdks is 21MB, 6.5MB
of which are .hg's metadata files. OpenLDAP's official repository is
in git, which makes doing something akin to our current client.py
checkout model annoying, so I assume we would switch to OpenLDAP by
importing a static copy of its build code into the tree. By
comparison, the mailnews, mail, and suite directories are each about
22-25MB, which means we would be increasing the size of comm-central
by roughly 1/3 if we imported it to hg.<br>
That said, it's still possible to trim down the directory-size of
OpenLDAP. It has 7.2MB in a doc directory which could be removed;
another 3.5MB in a contrib directory which is even easier to delete
(no references in scripts); 2.7MB in the test directory; 7.0MB of
code for the server-side components. Removing any code other than
the contrib directory would require modifying the configure and
Makefile.in files to remove references to these directories, but
this is not a difficult task. I'm assuming that the contrib and doc
code would definitely be deleted, as they contribute nothing to
Thunderbird, bringing import size down to 16MB. The OpenLDAP
server-side code, though large, would be useful to have for test
purposes. Being able to validate the code of comm-central-built
OpenLDAP via the tests is potentially useful, but the test suites
are not fast to run and definitely require server-side code.<br>
4. Integration in build system.<br>
As I alluded to earlier, there are multiple options for handling
OpenLDAP. We could:<br>
a) Treat it like a system library, and provide scripts for
building it before our build.<br>
b) Add a --with-system-ldap that uses the system LDAP library,
and build OpenLDAP via subconfigure if not present. Distros would
probably love us. Note that --with-system-ldap does provide some
interesting issues if we wish to reuse slapd for LDAP tests.<br>
c) Unconditionally build OpenLDAP as a subconfigure, or perhaps
guarded with an --enable-ldap option.<br>
Note that mconley's addressbook work would eventually reduce our
dependency on LDAP to a runtime library dependency via use of
ctypes. Until then, however, we would need OpenLDAP to precede
ldap/xpcom in our build configuration. OpenLDAP, for our purposes,
can easily build via |make| followed by |make install| (we would
override prefix to install libraries into dist/lib and headers into
dist/include).<br>
5. Other requirements<br>
OpenLDAP apparently relies on the Cyrus SASL library for SASL
support. This means that just checking out OpenLDAP won't give us
SASL support, which is a bigger problem on Windows and OS X than on
Linux, where I suspect we'd use system OpenLDAP libraries (likely
configured with SASL support) instead. For comparison, the ldapjs
library also lacks SASL support, while the Mozilla LDAP SDKs does
include SASL support. There's also some other includes apparently
necessary for a subset of the server backends, like db.h; I haven't
played around with backend server configs, though.<br>
<br>
Thoughts on ways forward:<br>
Replacing our underlying LDAP library is a big change that shouldn't
be taken lightly, especially when we have no test coverage of our
LDAP code as-is. It has been suggested in the past (via a comment on
one of my blog posts) that we rely on OpenLDAP's server for test
code; if people indicate that switching to OpenLDAP is a desirable
outcome, then this would be an acceptable way to start writing LDAP
tests IMHO. The way to move forward would then look like this:<br>
1. Include basic functionality tests for LDAP using a version of
LDAP that is assumed to be installed. Obviously, these wouldn't run
on tinderbox as-is, but they would work for people working on doing
the migration. Perhaps these tests could be enabled if a configure
option like --enable-ldap-tests=/path/to/slapd. I already have some
ideas about how the slapd binaries could be hooked up to a JS
controller (it involves a lot of nsIProcess.run, so this may cause
trouble if used in mozmill tests :( ).<br>
2. Include a --with-system-ldap flag that would use system-installed
libraries instead of ldap/sdks for our ldap/xpcom code. Equivalent
correctness could be verified with the LDAP tests, and Linux distros
could use these flags instead and fix the biggest problem with
Mozilla's LDAP implementation right now. It's also possible that
this could be the end state of our LDAP switch-out: we'd support
both versions of LDAP, and fallback on Mozilla's implementation if
OpenLDAP isn't installed.<br>
3. Drop a copy of OpenLDAP into our tree and delete the code for
using Mozilla LDAP SDKs.<br>
<br>
<br>
Thoughts/questions/comments/concerns?<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
News submodule owner
DXR coauthor</pre>
</body>
</html>