LDAP autocomplete

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

LDAP autocomplete

In bug 452232 I have recently been granted review on a patch which
creates a JavaScript component to perform LDAP autocomplete. This
component can be enabled via the
--enable-incomplete-toolkit-ldap-autocomplete configure option. Note
that so far the component only provides basic autocomplete
functionality, so it cannot yet be considered as a replacement for our
current code.

The advantage of this component is that it uses the toolkit autocomplete
interface, thus making it possible to remove some old XPFE autocomplete
code from the build, and potentially making it possible to build
Thunderbird without using XPFE autocomplete at all, however I don't know
whether anyone has looked into that possibility yet.

Additionally this helps us creep ever closer to being able to build with
external linkage. The remaining issues to building with external linkage
are as follows:

    * LDAP autocomplete still uses some code that we currently link into
      libxul. If you want to build with external linkage but without
      using the above JavaScript autocomplete component, I have a patch
      in bug 707305 which you can apply to build the autocomplete
      component with external linkage. (The patch does not affect
      standard builds.)
    * In bug 560772 Callek checked in a patch that used a method that is
      exported by a library that we don't link to yet; a patch to fix
      the linking has been reviewed but not checked in yet.
    * In bug 491843 IanN checked in a patch that used a method that
      isn't available with external linkage; no patch to fix this has
      passed review yet.
    * The new mail notification used by Thunderbird on Windows uses a
      method that isn't available with external linkage; I don't know if
      a bug has been filed on this.

As well as not building out-of-the-box, the other disadvantage of the
external linkage builds is that they are probably slower to run. So, why
might you want to build with external linkage?

    * Changes to mailnews C++ files don't require relinking libxul.
    * Linux distributions may be interested in shipping several Gecko
      applications built with the same libxul SDK.
    * Yesterday I checked in a patch to allow
      --enable-incomplete-external-linkage to work without using

Warning: May contain traces of nuts.
dev-apps-thunderbird mailing list
[hidden email]