A new address book: help wanted

neandr at gmx.de neandr at gmx.de
Wed Nov 27 16:46:18 UTC 2013

Today I found myself beamed years back to the time I started to use Tb 
and it's Addressbook.
One of my customer came along with problems using Lists in an AB. I 
found he was using the TB/AB List  with Contacts without a mail address.

Why is this a subject for this thread?

First and YES, I know contacts added to TB/AB List *needs* a mail 
address! But adding such a contact will "corrupt" the List! No further 
addition of contacts possible!

Second. The "normal" user expects an Addressbook *NOT* only to use it 
with the mailing system. He/she expect to have a system which handles 
all his/her contacts for the day-to-day use. And YES, using it for the 
mail system is one requirement -- but today more then ever -- for all 
the contact related work, on a PC, on a mobile device, on .. etc -- with 
and without mail addresses. One application for *all* his need!

A redesign/rework of TB/AB which meets that goal can be also a great 
chance to make Thunderbird a better choice. I hope the project has this 
in mind.

Mozilla/Netscape/Thunderbird fan / user since decade(s)
Extension developer

Am 27.11.2013 17:27, schrieb Joshua Cranmer 🐧:
> 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]

More information about the tb-planning mailing list