Future of Thunderbird - fix it, or total rewrite? WAS Re: What happened to hiring an architect?

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Wed Dec 28 17:05:04 UTC 2016


On 12/21/2016 10:27 AM, Disaster Master wrote:
> Hello TB-Planning members (and especially Ben/Jim),
>
> This email is to address those who have been stressing that we should 
> not even consider the option of forking Gecko if/when we get to the 
> 'fork or die' stage, but should just immediately focus efforts on a 
> total rewrite of Thunderbird from scratch.
>
> First, please understand that I actually love the idea - but only with 
> some caveats.
>
> First, to resources. As everyone here knows, TB dev resources are very 
> limited right now.
>
> My understanding is that most-if-not-all of the existing resources are 
> currently focused on just keeping up with the changes Firefox is 
> pushing, as well as some smallish but very welcome bug and feature 
> fixes. So, the main question has to be, just how much of existing 
> resources could be re-focused on a total rewrite (whether it was 
> Glodastrophe or something else)?  Obviously, resources working on 
> feature fixes are an option, but this is really a question only Kent 
> or a few others can address, and I would really like to hear from them 
> on this. The key point being, if it isn't enough to even remotely come 
> close to getting the job done in the time-frame. For the one biggest 
> problem about that particular question - meaning, what exactly is our 
> time-frame - see my prior email about the removal of XUL/XBL(/XPCOM).

The problem with rewriting is that rewriting is really hard, especially 
when you have something as feature-rich as Thunderbird. If you want to 
rewrite MIME, for example, you need to be sure to include support for 
PGP, S/MIME, uuencode, and yEnc before you can really turn it on, and 
you also have to work out which features are to handle real-world 
annoyances (e.g., Outlook's charset idiocies) versus bugs that no one 
figured out how to fix (e.g., multipart/alternative handling). You can't 
really turn to existing libraries to handle these issues--no one is 
using those libraries in a wide enough net to catch the issues you find 
in real usage. Even something as simple as SMTP--which largely boils 
down to "send this mail to these people using this account, with a few 
extra options"--actually requires a surprising amount of work to 
reimplement (mail delivery notifications, SASL auth, reporting of 
capabilities, etc.).
>
> If the project goes down this road, I can envision a large job for 
> those like me who are not programmers, but love TB nonetheless, of 
> going through the current bugzilla for TB, and compiling a (probably 
> long) list of bugs/enhancements that should be worked into the rewrite 
> goals, and creating new ones too.

We've tried this in the past, most notably in the address book. It's 
been clear for as long as I've been working on the project--that is, 
since 2007--that our address book is deficient in multiple ways, and 
we've held off some features for the coming address book rewrite. The 
main features that come to mind are the more-than-2-email-addresses bug 
and, more lately, CardDAV support. Given the size and complexity of 
rewrites, however, we've basically avoided adding features for something 
we thought we'd finish within a year that we haven't finished 5 years 
later. Even the fact that we had a contributor actively dedicating his 
time to moving forward on the rewrite hasn't been enough to push the 
rewrite to completion.
>
> Something else I just thought of. I seem to recall a long, long time 
> ago, I believe it was in Netscape 4, there was an ability to store 
> your settings in LDAP. I'd also love a way to do something similar, 
> maybe not in LDAP. Imagine, you get a new computer, install the shiny 
> new TB, and the first time it opens, there is an option to 'Import 
> Settings'. This could be from a local file, or how about a WebDAV 
> server? Dropbox? FTP server?) - you enter the required 
> info/credentials - and presto, TB restores all of your settings - 
> Accounts, Passwords, Addons and their configs, etc.

We have talked about leveraging Firefox Sync in the past to synchronize 
settings across TB instances, and we had at one point a provisional OK 
from the Sync team so long as we're not storing oodles of information 
like local messages. At the time I last recalled talking with them, they 
were telling us "hold off, we're completely rewriting the thing in the 
next few months" (yet another example of the underestimation of rewrite 
complexity). Since then, I did hear a story from the SeaMonkey folks 
that the Sync people were moving goalposts to reject being usable for 
SeaMonkey, and, given the confused Mozilla policy with respect to 
Thunderbird, it's unclear if we could leverage that service still.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist



More information about the tb-planning mailing list