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

Disaster Master disasterlistmanager at gmail.com
Wed Dec 21 16:27:44 UTC 2016


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).

If it is taking all (or even most) of the current resources just to keep
up, then refocusing those resources on a total rewrite is not really a
viable option either, unless new resources are found. That said, I
readily admit that this is a real possibility (especially after Kents
welcome news about the status of donations coming in!), as there may be
a lot of devs out there who would be more inclined to work on something
shiny and new, rather than slowly fixing/rewriting parts of something
old and crufty.

That is a big question mark at this point, so I'll leave that on the table.

However, I also have an even more important point to make.

In order for a total rewrite to be a valid option, then it must by
definition include a formal and very strict goal of actually duplicating
TB's current UI/feature set to a great extent, especially including the
ability to customize the UI and feature set just like you currently can,
both with Addons, and probably as well as directly through config
file(s) (like you currently can with user.js, userChrome.css and
userContent.css).

The bottom line is, anything else simply doesn't qualify as a 'rewrite
of Thunderbird', it is just the writing a new email client from scratch.
Of course, this is not a bad thing in and of itself, but Thunderbird
lovers want a shiny new Thunderbird, not just another new mail client,
and if TB resources are to be used for such a project,
UI/customizability/feature-set parity with current TB is an absolute must.

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.

Personally, I would also argue for a modular approach for key
functionality - the three big ones I can think of off the top of my head
being the Composer, the HTML rendering engine, and mail storage engines.
These could be implemented as what Kent referred to as 'FirstClass
Addons'. For the Composer, there are a number of open source HTML
editors out there that claim to be 'drop-in' capable, so this one should
definitely be doable. We could just pick the best one, implement it as a
FirstClass Addon, and if anyone prefers another one - just implement it
using the existing Addon as an example/starting point. You're on Windows
and prefer to use the Microsoft Edge (or Opera) rendering engine?
Develop an Addon to enable it (it would obviously require the desired
engine to be installed and available). You're on a Mac and prefer the
Safari rendering engine? Same thing. Now, the rendering engine would
likely be a lot harder than the editor to get right - maybe even
impossible for some engines due to lack of API/hooks - but I know that
Outlook used to use the IE rendering engine (I recall the huge outcry
(still ongoing) when MS switched it to use the Word rendering engine),
so it apparently can be done, the only question is if it is feasible. 
For the mail storage formats, start with Addons for maildir and mbox
formats, then someone could add support for dovecots m/sdbox formats too
if they wanted.

Oh - I would also strongly recommend reaching out to the main IMAP
server developers/projects (dovecot, cyrus, fastmail, others(?)) for
ideas and input an the design of the core/inner workings (not the UI).
Timo (dovecot author and primary dev) has expressed an interest in
writing a new email client (I think he mentioned it would primarily be
IMAP based), and I think his input would be extremely valuable.

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.

Man, I'm drooling now.

Ok, enough of my meanderings, time to go get some work done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161221/ceea9163/attachment.html>


More information about the tb-planning mailing list