<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello TB-Planning members (and especially Ben/Jim),<br>
<br>
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.<br>
<br>
First, please understand that I actually love the idea - but only
with some caveats.<br>
<br>
First, to resources. As everyone here knows, TB dev resources are
very limited right now.<br>
<br>
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).<br>
<br>
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.<br>
<br>
That is a big question mark at this point, so I'll leave that on the
table.<br>
<br>
However, I also have an even more important point to make.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Man, I'm drooling now.<br>
<br>
Ok, enough of my meanderings, time to go get some work done.<br>
</body>
</html>