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
Mozilla/Netscape/Thunderbird fan / user since decade(s)
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
> 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