A point of reference

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Thu Mar 8 04:58:11 UTC 2018

On 3/7/2018 3:47 PM, Ben Bucksch wrote:
> Joshua Cranmer 🐧 wrote on 07.03.18 21:27:
>> On 3/7/2018 3:19 PM, Ben Bucksch wrote:
>>> Most of these are in the form of webapps replacing older native apps.
>>> Most users use Gmail instead of Thunderbird and Outlook. That 
>>> includes power users that are speed-sensitive. In fact, that's 
>>> Thunderbird's main competitor: webmail.
>> That's an apples-to-oranges comparison. An email client (to a first 
>> approximation) is centered around a core database, and it's the 
>> database operations that are performance sensitive.
> If indeed the DB turns out to be a bottleneck, there's no problem in 
> using a native C library for the database - e.g. sqlite, or something 
> else.

It is not an easy task to swap out something as key as a database. Since 
an email client is largely a view around a database with some backend 
tasks manipulating it, the nature of that database will tend to dictate 
the API. We've known for years that Mork is not capable of achieving the 
performance endpoints that we want, but we can't easily change it to 
another database because the API relies on key characteristics of Mork 
(e.g., sync access to all objects once the database is opened).

This is why I've harped on so much about achieving specific performance 
endpoints. We know performance is an important feature for our users, 
and if we're rewriting the database, it is dereliction of duty to not 
look towards achieving that performance from day 1. This is why I 
advocate for challenging performance metrics from the onset: if we can 
handle a million message folder now, we have an API capable of achieving 
high performance on more modest folders even as we load it down with 
more functionality over subsequent iterations. We can no longer expect 
platforms to naturally provide us with speedup to cover the extra load 
in the future.

> Joshua, if you have specific ideas about how a future Thunderbird 
> database should be designed, in API and in implementation, please do 
> write your thoughts down (in a new thread, or on the wiki), so that we 
> can include them, if we ever get to implement something new for 
> TB:Gecko or TB:NG.
I've opined about DB design several times in here and/or m.d.a.t. 
There's even a document floating around with a WebIDL definition for the 

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

More information about the tb-planning mailing list