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
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
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning