Big Missing Pieces

This is a big project, and I'm only one person, and I'll only be able to work on this in my part time. This is my unsorted list of big things that are missing that I'll likely need help on.

The entire front-end (the design of which is still in flux and being iterated on)

• Contacts list
• Contact detail view
• Contacts detail view (when multiple contacts are selected)
• Importing "wizard"
• Preferences

API and connectors to external contact providers

• LDAP (via js-ctypes bridge to OpenLDAP library?... We need to understand what is happening to Mozilla's LDAP library).
• Google Contacts
• System Address Books (via ContactsAPI? What's the desktop story there?)
• CardDAV
• Linagora's OBM

API and connectors to profile providers

• Facebook
• Twitter
• LinkedIn

Thunderbird integration points - must be made asynchronous

• Anything that uses cardForEmailAddress needs to be redirectable.
• This code, which bumps contact popularity on mail send.
• nsMsgDBView::CellTextForColumn - called by the tree widget to paint the thread pane. We look up the display name of the sender via the e-mail address of the msg hdr. We cache the result in the msg hdr, so it's only the first paint that's slow. Potential work-around - if we don't have a cached result, display the actual sender, kick off a query to find the display name; when that comes back, if it's different than what we displayed, update the cached result, and invalidate the row. We'd want some smarts to avoid doing the same query multiple times.
• nsMsgContentPolicy::ShouldAcceptRemoteContentForSenderWe need to figure out what we're doing with accepting remote content - are we storing that stuff in the AB?
• nsSpamSettings::CheckWhiteList - This is used when the user says to whitelist a particular address book as not junk, which cuts down on false positives, and junk processing time. We could move the address book checking part of this method into the spam filter plugin, which is already async, and leave the domain trusting part. So, if the user whitelisted any address book, we would tell the spam filter plugin to first do an async query to see if the sender was in a white listed address book before it starts fetching the message and doing the spam analysis. This pushes the white listing into the spam plugin, but we only have one real spam plugin anyway.
• nsMsgSearchTerm::MatchInAddressBook - This is used in search and mail filters, e.g., when the user adds a filter term that checks presence of sender in an address book. Filter processing of incoming mail is strictly synchronous right now. We could redo it to be asynchronous for pop3+imap. This is a non-trivial task, but it would allow us to do more interesting things in filters. Or, we could postpone the start of filter processing until we have finished any possibly needed ab lookups (though filter term application is lazy currently, which is a nice property). Or we could remove this capability, though that goes against the idea of doing more leveraging of the address book data.