Addressbook

[romanofski]

We need a way to store and retrieve addresses. This might also be something which could go into a plugin, while the most basic form could be simply parsed from a file similar to what mutt does.

Thinking of it, it would be nice if there are multiple forms addresses can be looked up. Just because you might keep some addresses local, but have access to an ldap server.

[frasertweedale]

The challenge here that composing mail will be done (of course) by invoking $EDITOR unto a tempfile. So we first need to decide if it is in scope or not.

I guess we can make it a first step separate from the editing, or edit just the body and have purebred handle all addressing.

In which case we want something like:

type AddressBook = AddressSearchTerm -> IO [RFC822Address]

Then it is easy to have multiple AddressBooks; just traverse them, merge the results and present to user.

[romanofski]

I was thinking of mutt, in which the workflow goes:

• enter subject
• invoke editor on tempfile in which you write the body, save, quit
• final mail view in which you change To:, Bcc:, CC:, etc and the attachments

The final point allows you to query different address books with different commands. I always perceived it as a good workflow, however I might have just learned it the way it is. You think this can be improved?

[romanofski]

Notmuch has now a way to retrieve addresses based on search terms from the existing mail corpus. We should definitely use that as a first class citizen. Perhaps that alleviates to keep some kind of addressbook file. I guess to support other address retrieval (e.g. LDAP), that could be implemented in a plug-in.

[frasertweedale]

Do you mean notmuch_thread_get_authors? I have a couple of concerns about that:

1. Performance. It's per-thread. Not efficient. Maybe useful as a one-off for building / importing addresses into a separate address book database.

2. It would return duplicates (i.e. addresses with/without the display name) so there is extra work to "merge" different addresses that refer to the same mailbox.

IMO it's out of scope for purebred itself, except probably for an interface to import addresses (as they are encountered) into an address book.

We should begin to think about / sketch the API / plugin interface for address books.

[romanofski]

I looked only in the CLI, since I thought being able to search the addresses in Xapian shouldn't be much of a problem. I did not check how it was implemented. I think having a small tool to populate an address book might already be enough if it really is just the function you were referring to.

[frasertweedale]

@romanofski the notmuch address command:

1. does a xapian search for all messages matching the query, and iterates them
2. if --output=sender is given, the file has to be opened and parsed to read the To, Cc and Bcc headers. Otherwise only the From header is looked at (which is indexed, so file does not have to be parsed).
3. stuff the addresses into a hashtable and output the result.\

So, it is not efficient as part of an automatic address book population. Separate small tool, sure.

[romanofski]

What do we settle as an acceptance criteria for this item? Implement a way to retrieve an address based on an IO action, which will default to retrieve the address from a text file? As a text file, lets use the mutt address file format?

[frasertweedale]

I think MVP would consist of:

• API: monadic read / lookup.
• A file-based implementation (I'm fine with mutt format)

Then later we can add:

• Adding new entries to address book
• Saving the updated address book.

The API should work with addresses and be completely ignorant of how they are actually stored.

[romanofski]

Going to pick this one ...