logo
Header graphic 4 of 8

Downloads

Funambol Connector for Thunderbird 11

This version has been archived and is superseded by a release for Thunderbird 13.0. It will NOT be updated: Click here to go to Version dev13.

Release notes for version tb11-dev11

This version is a major update over dev10. It contains an update to the Funambol C++ API used as the back-end of this software. It's based on changeset 105e8c05d32d.

Automatic updates are provided through files.maurus.net. I currently intend to support this service until the add-on is stable enough so it can be reintegrated into addons.mozilla.org, which would be the right place for it.

It's going to be interesting to see how many people opt to stay on the 10.0 ESR release.

News

Gecko 11.0 marks the landing of Bug 650304 that switches GCC-based versions of Mozilla to using "-std=gnu++0x" and the introduction of stdint.h support. Both changes required updates to the Funambol add-on's build configuration.

The update to Funambol C++ API v9.0 now requires at least Microsoft Visual Studio 2008 to build. So if you want to work with the api9 branch from source.maurus.net make sure that you have a recent version of Visual Studio. I'm now building the Windows version of the add-on with Visual Studio 2010. If it proves to be stable, it is likely that I will remove support for Visual Studio 2005 from the project with the release of dev12.

An updated note about time zones

While turning on this option fixes some of the problems, Lightning, the Funambol Mozilla plug-in and the Funambol server still don't play nice completely. As soon as the next Thunderbird update crisis is behind us, I will start investigating again.

The future

I have plans to move this plug-in to a more stable condition before starting any work on new features:

  1. The first and most important thing is to move the configuration engine out of the Funambol stack to a new system based on Mozilla's preference system. Picture sync as a future feature will rely on this.

  2. As a second step, the add-on should then get back support for the MozillaTransportAgent, which, based on FunambolThreadProxy, might be possible now. However, this work should really be done outside of the Funambol API. I have no idea why this class has been moved into the API to begin with.

  3. Finally, really clean up the UI JavaScript code and the UI itself. The preference panel is unnecessarily complicated in my opinion. The subdialogs to choose a calendar and address book to sync, for example, should be removed.

About the add-on

This is the eleventh iteration of the Funambol Sync Plugin port and the first one to support Gecko 11.0. This is by no means a production release. It should be considered unstable and for development purposes only. This document lists most of the changes that were necessary to Funambol Mozilla-Plugin revision 339, which I branched for this version.

I'm doing this work for myself, as Thunderbird, Funambol for iPhone and CalDAV have become invaluable tools for me. I want to share this with the broader development community in the hope that development will be picked up by Funambol again. I want to be absolutely clear: I do currently not intend to support this project beyond my personal needs. Hopefully someone else can pick this up, branch out to their GitHub/Bitbucket/LaunchPad and do something with it, especially find a way out of Mozilla's fast-release hell and provide a MAC OSX-build. I would implore you, however, to then change the filename and about dialog accordingly. The one thing the world does not need is 20 different Funambol connectors all looking like official software versions. This is why this version currently bears my company's name and a link to the source code on this site.

To make this clear: If you recompile this build, please change the version number and remove all references to maurus.net, preferably replacing them with a clear indication of where to find you, not me.

You can find the current source code of this build here: Mercurial source repository (maurus.net)

You can clone this repository like this:

hg clone http://source.maurus.net/funambol funambol-mozilla-plugin
cd funambol-mozilla-plugin
hg update api9

There are experimental Windows and Linux builds which both include debug symbols at the top of the page.

This build has no support for Sunbird as I couldn't possibly build and test that! It supports only Thunderbird v11.0.

Issues

There are a couple of known issues, most of which are explained in more detail down below under "Changes".

  1. The connector uses the underlying operating system's CA store.

    The Linux build relies on a statically linked version of libcurl and libssl for HTTP communication, while the Windows build relies on the Microsoft HTTP stack. This can result in a "error code 2050" when trying to sync to your server over HTTPS.

    Should you use a HTTPS server with a self-signed certificate or your own CA, you must add this CA to your Linux distribution's CA bundle or import it in the Windows Control Panel's Internet Options. It's not enough to add the certificate in the Thunderbird options dialog! The Mozilla-based HTTP transport is as far as I can see broken beyond repair due to changes introduced in Thunderbird 5.0. On Ubuntu Linux-based systems you import your own CA certificate by putting it in /usr/share/ca-certificates and adding it to /etc/ca-certificates.conf and then running sudo update-ca-certificates. Consult the documentation for your Linux distribution if in doubt.

    In any case, the statically linked version of libcurl consults the file /etc/ssl/certs/ca-certificates.crt as its ca-bundle. If your distribution doesn't provide this file, you can simply create it, or recompile the Funambol connector as described below and change the path while configuring libcurl.

  2. The connector might leak memory.

    Most of the nsISupportsProxy instances have been removed. They were probably a huge source of the memory leaks. More importantly however, the old Funambol codebase doesn't always use nsCOMPtr where it's supposed to. I think I caught most instances, but the add-on could use some introspection with a memory profiler.

  3. The JavaScript-code is a mess.

    The code in sync-dialog.js is a mess due to the asynchronous AddonManager and me messing around with a JavaScript module pattern that fits websites much more than XUL applications. The UI code needs a major refactoring. The way it is now, it will become a real maintenance headache. On the other hand, the threading code already is, so ... it can't get much worse :-).

    Beginning with version dev10 I started cleaning up this mess.

Changes

Porting the code to the Mozilla 2.0 codebase took a lot of work. There are multiple issues with Funambol's code to begin with and the code hasn't aged well. I had to sift through a lot of multi-threading issues. In general, most of the issues are listed here: Making Add-Ons compatible with Firefox 4.

This version of the Funambol connector contains fixes and work-arounds for the following issues:

  1. The Extension Manager has been removed in favor of an asynchronous approach.

    To fix this, I made extensive changes to Funambol's JavaScript source-code, but the current version is by no means perfect. In fact it might even contain multiple race conditions where the user could start synchronization before the Lightning Calendar component was loaded asynchronously. At least I was able to move most of the calls into the Extension Manager without issue to a central place inside com.funambol.util (utils.js).

  2. JavaScript objects can't be passed around threads anymore and nsIThreadManager is useless from JavaScript. Also, nsISupports proxies have been removed.

    This means that sync-client.js didn't work at all and I removed it. As a quick work-around I rewrote the JavaScript-based threading code as a binary XPCOM component called FunambolSyncThreadShim.

    A related problem is that there is no real replacement for threads in JavaScript. Some people might be able to use the "privileged" version of HTML5 WebWorkers called "ChromeWorkers" to perform their background work. However, ChromeWorkers don't have access to Components.classes and are therefor totally useless to us.

    Due to the above changes, almost all XPCOM components now contain assertions to make sure that they're run on "their" thread. So I rewrote the initially proxy-based code completely using a preprocessor-based code-generation strategy (FunambolThreadProxy) to compensate for that.

  3. Linux support needs static linking of libcurl, as MozillaTransportAgent is not usable anymore.

    On a debug build XMLHttpRequest-instances can't even be created outside of Mozilla's main thread as they're completely not threadsafe. This means that the MozillaTransportAgent class in Funambol's API is now completely useless for asynchronous operation. On Windows, Funambol uses Microsoft's HTTP stack by default anyway, but on Linux the connector needs another mode of operation. Unfortunately the previous method for using shared system libraries through an extension stub hasn't been updated for the Mozilla 2.0 extension model. Also a missing library would be hard to handle. I solved this problem by aggressively linking the connector statically to all its dependencies (libcurl, libidn, libiconv, libssl, libcrypto, libz). The upside of that is that the Curl-based transport is much more stable and tested.

    The downside is that security fixes won't be applied by a package manager update. I'm willing to overlook this for the time being, as you shouldn't point your Funambol connector at untrusted servers very much by definition :-).

  4. XPCOM component registration was completely revamped.

    This means that addons relying on XPCOM binary components must be recompiled for every new version of Firefox/Thunderbird. The only way (also called the "official way") for getting around this is to move to JS-ctypes. This might have been the point of the (defunct) "JS" branch on Funambol SVN, but since the removal of the ThreadManager from JavaScript it's pretty much useless for us.

    The bottom line is that as far as I currently understand it, plug-ins structured like the Funambol plugin, need either a strong support system to provide up-to-date builds for every 6-week release of Mozilla, or they need a major refactoring effort.

    I also made the necessary changes to the chrome.manifest and FunambolModule to work with the new registration APIs. Unfortunately, this makes my version of the plug-in completely incompatible with versions of Gecko below 2.0.

Source code notes and build configuration

Build environment

I'm using a build environment on Amazon EC2 building with an old Visual Studio 2005 license that I had still lying around (VS2005 happens to be still the official build system for Firefox 6). For the Linux build I'm using a 64-bit Ubuntu 11.04 EC2 Large VM and a 32-bit Ubuntu 11.04 EC2 Medium high-CPU VM, both based on Alestic's excellent AMIs, which I can probably make available to you as all the software is open source. I'm looking into it.

Common changes

  1. I updated all the copyright notices in the files to 2012.

  2. This build of the plug-in installs into extensions/syncmlplugin[AT]maurus.net so that it does not clash with a potential Funambol build. However, installing them in parallel is, of course, not recommended.

  3. I changed the "About"-dialog to reflect the GPL licensing and mark this build as a maurus.net build.

  4. The shell-script based build-system now edits chrome.manifest depending on the platform and adds the correct name for the plugin's shared library.

Windows build

  1. The Visual Studio projects in my repository have been converted back to Visual Studio 2005 like they should be (as implied in the original Funambol release notes). Funambol Inc.'s Subversion only contains Visual Studio 2008 projects.

    However, since dev11 introduced support for Funambol C++ API v9.0, the Windows build of the add-on requires at least Visual Studio 2008 to build against that version of the API. If it proves to be stable, it is likely that I will remove support for Visual Studio 2005 from the project.

    Regarding the build setup, this version uses:
    Microsoft Visual Studio 2005 (I had a version lying around. However, it might be possible to use the free Visual Studio Express 2008 instead)
    Simple Thunderbird build
    Update for Visual Studio 2005 (SP1) required to build
    Windows SDK 7.0
    Direct X SDK
    Thunderbird 11.0 source code

  2. I used the following .mozconfig file:

    ac_add_options --enable-application=mail
    ac_add_options --enable-calendar
    ac_add_options --with-windows-version=601
    ac_add_options --disable-installer
    ac_add_options --enable-debug
    ac_add_options --disable-optimize
    # fix sqlite missing symbols, see 
    # http://www.archivum.info/mozilla.dev.builds/2009-08/00041/ \
    # unresolved-external-symbol-_sqlite3_mutex_held.html
    ac_add_options --disable-tests
    mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-debug
    
  3. I needed to make a couple of changes to the compiler and linker configuration:

    1. Force include dist/include/mozilla-config.h

    2. Comment out the redundant //#define WIN32_LEAN_AND_MEAN in fscapi.h

    3. winnt.h defines #define DELETE (0x00010000L) and that clashes with CalICalendar.h. I changed that constant's name to CAL_DELETE and so on.

    4. In "C++ -> Code Generation" set "Runtime Library" to "/MT(d)".

    5. Change the linker configuration so it links against mozalloc.lib.

Linux build

  1. As mentioned above, the Linux build is statically linked against all its dependencies that are not part of Mozilla. These are configured as follows:

    • libiconv

      ./configure --disable-shared --prefix=/home/ubuntu/deps/libiconv-1.14 \
        --with-pic
      make
      make install
      
    • libidn

      ./configure --with-pic --disable-shared --prefix=/home/ubuntu/deps/libidn-1.22
      make
      make install
      
    • libz

      ./configure --prefix=/home/ubuntu/deps/zlib-1.2.5 \
        --static --with-pic
      make
      make install
      
    • openssl

      ./config -fPIC no-shared --openssldir=/home/ubuntu/deps/openssl-1.0.0d
      make
      make install
      
    • curl

      ./configure --disable-shared --with-zlib=/home/ubuntu/deps/zlib-1.2.5 \
        --with-ssl=/home/ubuntu/deps/openssl-1.0.0d/ \
        --with-libidn=/home/ubuntu/deps/libidn-1.22/ \
        --prefix=/home/ubuntu/deps/curl-7.21.7 --disable-ldap --without-gnutls
      make
      make install
      
  2. I used the following .mozconfig file:

    ac_add_options --enable-application=mail
    ac_add_options --enable-calendar
    ac_add_options --disable-installer
    ac_add_options --enable-debug
    ac_add_options --disable-optimize
    ac_add_options --disable-tests
    mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-debug
    
  3. The Funambol API was built like this:

    ./autogen.sh
    ./configure --prefix=/home/ubuntu/funambol/funambol-mozilla-plugin/funambol-lib/ \
      --disable-shared --with-pic --with-transport-agent=curl
    make
    make install
    
  4. The new Makefile.static in syncmlcomponent/build/posix can be used to build a statically linked build. Please note that many libraries are repeated multiple times inside the g++ statement. This is no accident and necessary so all dependencies are linked.

    make -f Makefile.static
    

    After linking, you should use "ldd -r libfunambolplugin.so" to verify that the only unresolved symbols left inside the .so are Mozilla symbols!

Published: March 16th, 2012