Friday, October 24, 2008

Mailing list sanity

With IMAP fakeserver awaiting review, kill-rdf mostly out of my hands (well, except for the subscribe dialog, which needs something I didn't have this morning), my relatively big news change blocking on news connection sanity, and that sanity now just needing some final touchups, I decided to look around for some more things to start on. I therefore turned back to the address book rewrite, which I haven't touched for about a month. What better thing to fill up one's time than by performing the holy grail of the rewrite, mailing list sanity?

Why do I personally consider this one task to be so important? It's because mailing lists, as they stand, are obstinate little things. They are both cards and directories. As two distinct objects, naturally. Yet they are also not quite cards and not quite directories. That they don't fully implement the scope of either makes them unwieldy to work with: one has to invoke isMailList tests in several places. There are approximately 75 such checks in mailnews/addrbook/src alone.

The extent of reliant code puts me off trying to do a one-patch-to-fix-it-all, so I devised some partial steps:

  1. Make an nsIAbMailingList class…
  2. …and temporarily inherit it from nsIAbCard. This will allow me to remove the isMailList from nsIAbCard (in favor of an instanceof-like check) and move mailListURI to the new interface, thereby simplifying nsIAbCard to almost its final state (copy and equals need more work).
  3. Tweak the directory/collection interfaces so that they return nsIAbItem in key places instead of nsIAbCard. This still needs more spec'ing, but the basic framework is in place.
  4. Move nsIAbMailingList to inheriting from nsIAbCollection. Key milestone here in that mailing lists can no longer be viewed as cards.
  5. Flesh out nsIAbCollection. Doesn't need to be in this order, but this is around the latest feasible time.
  6. Shunt nsIAbDirectory mailing-list-specific stuff to nsIAbMailingList. At this time, mailing lists will also no longer be nsIAbDirectory objects.

Steps 1 and 2 are really more like Step 1a and Step 1b. If you're following along on the road map, these correspond to roughly items 3a (first two items), 3b (the last one), and an extended version of 2 (the third and fourth ones). Nice and simple, the changes are in nice, smallish, relatively atomic batches.

Oh wait. Outlook cards and OS X cards could also be mailing lists. The palmsync nsAbIPCCard (which inherits from nsAbCardProperty as well) also cares about being a mailing list. So to complete the first step in the hackery—making the mailing list cards extensions of regular cards—I have to fix generation of mailing list cards in four different places, three of which I can't build on my normal Linux setup and one of which I can't touch on my Windows build (which I touch but rarely). Not to mention that this is probably complex enough to require a few patches on their own. At least fixing these issues will also fix a few ancillary ones as well…

In other news, I have a plan to do some Linux address book integration post-TB 3. This is no way related to any aggravation I may or may not have stemming from using as my primary development system one that has the least number of OS-specific code. I swear… :-)

1 comment:

Leni said...

The question may be premature, but I'm curious to know what the final relationship will be between cards, lists and directories.

In google for example:
http://code.google.com/apis/contacts/developers_guide_protocol.html#Groups
a card has 0 or more references to the lists it's a member of.
A specific interface (google URI) returns the list of lists.

Great that this is making progress, lots of users would like sane mailing lists!