Just for fun

Some history first

First time i compiled LibreOffice (LO) in march 2012, it failed to compile in the seamonkey (moz) module (i didn’t enable it explicitly). I had many questions about moz integration in LO:

1. what has an office suite to do with a browser?
2. why it is enabled per default, if it’s something optional?
3. why it was failing to compile on my recent Ubuntu box?

Six months later i knew the answers to all these questions 😉

1. it is needed for Thunderbird address book integration and some other extensions.
2. it is (well was) not really optional: mail merge is an important feature, because sooner or later you want to send mails from your office suite to the recipients from your address book. To import the Mozilla Address Book (MAB) data, which is stored in mork file format, LO need some means to read and interpret that format. Because of lack of alternative implementations Mozilla itself was used for that purpose.
3. well here things started to become complicated. It was subtle linking issue: compiler tool chain configuration was changed on Debian/Ubuntu: “as-needed” became the default, breaking many tools and libraries, among other the moz module in LO. But why two distros had a compilation problem in the moz module and nobody noticed? Debian/Ubuntu maintainers disabled this “a strangely hacked up Mozilla binary” inside of LO.

The chronology of events was:

• All was fine: moz module could be compiled on Debian/Ubuntu
• Debian/Ubuntu maintainer disabled mozilla in LO: “It is NO OPTION to use obsolete, patched seamonkey for providing the Mozilla Adress Book stuff.  […] Thus it’s (let alone for security reasons) disabled in most distros.” link
• Debian/Ubuntu introduced a compiler tool chain configuration change, making “as-needed” the default (see here and here)
• folks tried to compile LO and it was failing on Debian/Ubuntu

At that stage I didn’t know the whole story but I could convince the LO dev guys to invert the logic and to make –disable-mozilla the default option. Finally I fixed the compilation problem (providing “-Wl,–no-as-needed” option) and forgot about that stuff.

Work on mork driver

Some time later a core developer sent me a link to this bugzilla issue and asked me if I would like to take a look at it. I was interested. Submitter of that easy hack did very impressive job with his in depths description. I started to analyse how all parts were matching together: mozab driver, profile discovery, MQuery, xpcom backend driver (part of seamonkey) and the new open source mork file parser. It was very quickly obviously that substantial part of old mozab driver implementation must be reused. After some deeper investigation of the old implementation and the new mork parser the whole picture was clear to me. Basically there are two use cases:

• MorkDriver Bootstrap:

• Query Execution:

Some words about mork file format. In a nutshell mork file format is a generic sparce matrix data structure. It matches exactly the requirements: in an average address book only a small part of possible properties is actually filled. I you would open abook.mab file, you would see something like that:

[keys]:
(83=FirstName)(84=LastName)(85=PhoneticFirstName)
(86=PhoneticLastName)(87=DisplayName)(88=NickName)
(89=PrimaryEmail) [...]

[values]:
(81=John)(82=Doe)(83=)
(84='John Doe')(85=jdoe@somewhere.org)
[...]

[rows]:
[1(^83^81)(^84^82)(^85=)(^86=)
(^87^84)(^88^81)(^89^85)
[...]

Well, there is no magic once you understand how it works. We have overlaping key and value namespaces that makes it some hard to understand. It was used to save the place (for which cost?). So the common construct in mork file is (^83^81). This is a so called cell and consist from pointer to column and pointer to value, i. e. in the record above the name is Joe, the last name is Doe and the email is “jdoe@somewhere.org”.

I sarted the implementation with a small utility: mork_helper.cxx. With it you can dump the whole content of your abook.mab file (using profile discovery to locate it first). Once it worked i shamelessly stollen substantial part of the old mozab driver, replacing more or less the interface to the backend and the backend itsef.

Conclusion:

It was really exciting time to work on new mork driver for LibreOffice. On linux platform the new mork driver would be shipped from release 3.7 on. However on windows old seamonkey binary continue to be packaged. On windows, seamonkey is also in charge for reading Outlook and Outlook Express file formats. There is no native (not deprecated) API for that. That’s pretty uncool. I’m thinking of extracting that part of seamonkey and use it directly (like open source mork parser) without shipping the whole seamonkey. Once in place we would hopefully be able to strip this “strangely hacked up Mozilla binary” from LO repository. And last but not least many thanks to all who helped out during the development and integration, especially Stephan Bergmann, Michael Stahl, Fridrich Strba, Michael Meeks, David Tardon and Caolan McNamara.

scratched