A new address book: help wanted

Joshua Cranmer 🐧 Pidgeot18 at gmail.com
Wed Nov 27 16:27:08 UTC 2013

On 11/23/2013 1:06 PM, Mike Conley wrote:
> Hey tb-planning,
> Over the past year or so, I've become known as "the address book guy". Anytime somebody asks what's happening with the address book, somebody points to me, and I tell them the same thing: "I'm working on it, but in my free time, which has been quite sparse as of late."
> Well, it's become increasingly apparent that I don't have the cycles to drive this project to completion on my own. If we're serious about trying to ship a new address book (or the moorings for a new address book) in the next major release, I thinks somebody better take the helm from me - somebody who can actually spare some time on it.
> Here is the state of things, just to give context:
> 1) The fragments of an add-on to replace the current address book exist here: https://github.com/mikeconley/thunderbird-ensemble. When I say fragments, I really mean it. It's gone through several design iterations, and I've backpedaled here and there, and it's really quite obvious that I've had a hard time moving past just creating the backend. I think the original decision of using Backbone.js for modeling and data binding may have been an error, but I could be wrong on that.
> 2) Jon Demelo, my GSoC student, worked on a connector for CardDAV. We've got tests and the rudimentary functions for receiving CardDAV records appears to work.
> 3) The platform change for bug 457296 landed, which gives us the ability to store remote content permissions in the Permission Manager rather than the address book. Thunderbird still needs to be modified to use this ability, and provide an interface for revoking those permissions.

This requires three pieces of work:
1. Actually modify the content manager to use the permission manager 
instead of the address book. There is already a draft patch for this, so 
it shouldn't be hard.
2. Display UI for managing the permissions.
3. A migrator to migrate the permissions from the address book to to the 
new UI.

> 4) I've filed a bug (Bug 841603) and created (now outdated) WIP patches for creating a generic contact service for other components to call into - this service can be overridden by an add-on so that a new address book could be swapped in.
> That last patch will need rethinking now that mozContacts is using WebIDL bindings as opposed to XPCOM bindings.

It's worth noting that the number of things people actually need the 
address book for outside of address book code itself is relatively 
small. The most common operation is "card for email address", where the 
queried properties boil down to "display name" (for header display), 
"popularity" (for autocomplete ranking and send updating), "prefer mail 
format." Alternate email addresses isn't used yet, but will eventually 
be needed to support EAI. The other operations are "expand mailing list" 
(given display name, get list of display name/email addr combos in the 
list) and "is in address book" (spam settings, search, filters). Gloda 
has some richer uses, I think, but it's in JS and can suffer to use WebIDL.

[The address search dialog (Edit > Find > Search Addresses) is also 
technically external to the address book, but when 3 out of 4 developers 
in a small meeting were surprised that the dialog existed, it seems to 
me that we could kill it when the old address book dies anyways, so it's 
not worth migrating to a new API]

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

More information about the tb-planning mailing list