I’ve been pretty bad about talking about the address book. Sorry about that. I’ve been pretty busy helping to get Instant Messaging shipped for TB 15.
But with IM polished off, I’ve (once again) started refocusing my attention to the address book.
So where am I?
The Ensemble Project
In short, I’m writing an add-on to experiment with approaches to a new address book. I’m calling it “Thunderbird Ensemble”, because every project needs a cool code name.
The add-on is in its very very early stages. Nothing is usable. Nothing is stable or guaranteed. There’s no UI yet, but there are some tests.
You can track my progress here.
Here are some highlights, implementation details and unstructured thoughts about the add-on, and where I’m going with it:
SQLite Storage Back-end
I’ve chosen to use SQLite (via mozStorage) for the contact database. I was originally toying with using indexedDB, but it’s lack of support for substring searches (which is necessary for things like auto-complete) wasn’t very appealing. I briefly toyed with throwing my own indexing layer on TOP of indexedDB, and then I realized that I was probably reinventing the wheel.
So SQLite it is!
Diffs, Diffs Everywhere
Contact records are a representation of the fields and meta data about a contact. My add-on will be able to calculate diffs between records, and those diffs can be applied on top of records to make changes.
So, for example, suppose I decide to make some changes to a contact – I add some email addresses, remove a phone number, and change a birthday. I’m effectively creating a diff.
Now we apply the diff on top of the original contact, and send the resulting contact record to the datastore for storage.
If the storage happens to be on the network, and the original record we applied the diff on to was out of date, we should get a fresh copy of the contact record, apply the diff, and try again.
With diffs comes conflicts resolution – but conflict resolution is never a pleasant experience, and I’d like the user to not have to deal with that if possible.
My solution is to just be optimistic – if a diff is asking to remove something that isn’t there, great! Mission accomplished! If the diff is adding something that already exists, no problem! We skip!
And for things that get changed, like birthdays, we simply say that the last writer wins.
Maybe that’s naive, but that’s the approach that I’m taking.
What do I have?
I can create contact records, diff them, apply diffs, and “merge” two records together. And I have tests for all of that work.
I’ve got the start of the SQLite backend working (basically, we can set up the database…but that’s it.)
I’m currently working on importing old Thunderbird contacts into Ensemble’s notion of contact records.
After that, I’ll work on getting them written to the database.
Comments? Questions? Complaints? Ask them here. It’s still really early on in the process, but if you find bugs in my code, please file issues on GitHub.
27 people like this post.