The Great Addressbook Rewrite

As I write this, bug 413260's first part is almost complete. At a diff of -2639/+1747 (47 files changed), the first portion is quite large. That said, substantive changes take place in only two files, accounting for over half the patch. A small portion is given over to the removal of nsIAbMDBCard, while the rest of the patch centers on merely changing the access points. Its size is mostly due to the large number of places it is accessed, not because the feature set is complex.

My original plan for implementation would have followed three large patches with errata in various other patches. The nsIAbCard is relatively self-contained and atomic, so that was how I came up with the plan. However, the startling results from attempting to do nsIAbDirectory refactoring makes this idea unfeasible.

My goal was to remove as much of nsIAbMDBDirectory as possible, which would require invalidating nsIAddrDatabase. That requires major changes to import and palmsync code. Throw in the difficulty of going from a file to an address book directory or a database to a directory and you get some hair-raising complexity. Then add in the fact that mailing lists are, well, black magic, and this process becomes especially complex. And large: my latest WIP touches some 68 files with a diff of a mere -693/+836.

What causes the sheer magnitude of difference in complexity? A card is quite lightweight: it is essentially a map of properties with a bit of extra stuff. There is therefore only one implementation of a card with five sub-implementations that refine it somewhat. A directory is the opposite: a heavyweight object with 4-6 (depending on how you count them) different implementations, sharing little meat among them. A mailing list is quite like black magic: they pop into existence when you need them, and creating one requires some non-intuitive steps.

So, what's my new plan? Well, lesson #1 is to stave off nsIAddrDatabase-gutting until after mailing lists are done. The next steps will be more atomic: the creation of nsIAbCollection and the involved refactoring come is first (probably split up into two or three patches), followed by mailing list sanity with nsIAbGroup (again, maybe a few patches itself). Only afterwards will I remove nsIAddrDatabase from import and palmsync (probably in two batches). Trivial removal of nsIAbMDBDirectory (i.e., where it is used for cardForEmail) will probably be in one of the first directory patches.

Of course, some of the more ambitious changes will need tests, but it looks like hwaara is being nice and writing tests for import (see bug 421050).