Highlevel Architecture Overview
There are a number of pieces to this, and some of this might require some experimentation to determine if what I'm proposing here is practical. I will highlight the areas where I'm unsure.
Here's what I'm proposing, at a very high-level:
Some components are numbered, and I will now attempt to explain each numbered component.
I think of this as the core of the new address book. This component is the "grand central station" where all requests to create, read, update or delete contacts will go through.
I want this to be a SharedWorker, because it's important to remember that multiple things (multiple Thunderbird windows, parts of Thunderbird) might want to communicate with the address book at different times. A SharedWorker allows us to contact the same worker across different windows and iframes, which makes it a "global" service. Note that in order to access the same SharedWorker, the things accessing it must share the same origin. This is one of the things I'm not entirely certain about: when Thunderbird loads these local scripts, I believe the origin will be the "System Principal", and I think it should work correctly, but I'm really not certain. We should experiment to make sure that chrome-privileged pages in Thunderbird can communicate over a SharedWorker.
Note that communication with the SharedWorker by its very nature has to be asynchronous, and use message passing.
In general, the SharedWorker should listen for messages for creating, reading, updating, and deleting contact records that it's holding in its cache (I'll get to the cache next).
The Mork database that Thunderbird currently uses for the address book has only one strength that I know of, and that's speed. It is very fast to query it. That's not because Mork is particularly clever, but because the database is loaded into working memory at startup, and all queries occur there; it's essentially an in-memory database.
I think we want to keep that performance characteristic if we can. What I'm proposing is that the new address book holds an in-memory cache of contacts that it can create, read, update and delete (synchronously from within the SharedWorker, asynchronously from clients that message the SharedWorker).
The SharedWorker and its Storage Cache will not have direct access to the disk - SharedWorkers simply don't get access to this. What I suggest is that when the SharedWorker is initialized, it gets passed a message that sends along the entire contents of the address book, which it then shoves into the cache.
Periodically then, the SharedWorker will send a current snapshot of the cache to something more priviledged (like the Hidden DOM Window, which I'll get to soon), which can then write those snapshots to the disk.
When Thunderbird starts to be shut down, it's important that we cease all writes to the cache, and then ask the SharedWorker for the last snapshot, which can then be written to disk.