Proposal to start a new implementation of Thunderbird based on web technologies

Ben Bucksch ben.bucksch at beonex.com
Tue Apr 11 01:42:27 UTC 2017


Hello Joshua,

first off: Thank you so much for the nice, level-headed response! This 
is the kind of discussion I was hoping for. This is productive and 
great. Thank you!

Joshua Cranmer wrote on 4/5/17 7:31 PM:
> every estimation for feature implementation I've seen from Mozilla has 
> been wildly optimistic

I'm not Mozilla. :-)
I've done rewrites and challenging tasks before, and typically kept my 
estimates.

>> I would rather convince others on a rational level, or if I'm missing 
>> some aspects or ideas, improve my proposal to accommodate valid needs 
>> that I've overlooked.
>
> Let's talk about the proposal then. For my part, I have one 
> non-negotiable requirement: we should be able to ship CardDAV support 
> to our users by 2018. Beyond that, I think there should be means to 
> implement new features in TB in a more rapid basis "if prudent"

Now, we're talking! This is getting somewhere. That's exactly the 
concrete level at which we should be talking.

Yes, I totally agree that the address book can't stay as-is until 2020, 
even in the old Thunderbird. Just 2 email addresses per person are just 
ridiculous. Sync is critically important these says, and CardDAV is part 
of that, yes. And I think everybody agrees that the old AB 
implementation is ripe to be trashed. So, this would be an excellent 
component to backport from the new Thunderbird to the old. I totally agree.

There are probably other such low-hanging fruits.

> 1. Delete the requirement that feature development in Thunderbird is 
> unfunded. It's okay to leave it vague which features would be 
> implemented sooner--the only two that really come to my mind are 
> CardDAV and EAI. Beyond that, I don't think that there are many 
> features which are urgent to implement (e.g., JMAP would be nice, but 
> no one's really clamoring for it).

*I fully subscribe to this.*

We are actually in violent agreement. What you wrote is exactly what I 
think as well.

(I've formulated it too extreme in my original proposal. I've tried to 
be short - already hardly anybody read my entire proposal, even though I 
tried to be short.)

Later:
> I've mentioned several times the Servo model, and if that's 
> essentially what you're proposing, I don't have problems with it. That 
> model (to me, at least) is that you use an entirely different product 
> to develop all of the backend pieces which you can then reintegrate 
> into Thunderbird as they become feasible replacements

Yes. And no. It's a balance of how much you backport and where you focus.

I think you described it best under point 1. You phrased the balance 
exactly as I have it in mind.

> 2. Make it clear that being able to transfer features to Thunderbird 
> is a priority. i.e., you'd rather a 100% complete address book and 50% 
> complete IMAP than 80% of both.

I'm not sure what you mean. But I don't think that when we rewrite, we 
should first complete 100% of the Thunderbird IMAP features before we 
start with address book, or vise versa. Rather, I subscribe to the MVP 
(Minimum viable product) idea. I want to first have a functional, but 
minimal and simple email client using only web techs (plus socket and 
file I/O of course, but still pure JS). That includes all of IMAP, POP3, 
AB etc., but not at the level of TB yet, but just the basics to read and 
send mail. Then, we build it out to be a good (not simple) email client, 
so that 80% of the users are happy with it. Then, finally, we build all 
the remaining TB features that the remaining 19% need. That's the idea 
of MVP.

(And yes, I left the last 1% of users. There will always be holdouts 
that insist on the most arcane features. There's no way to make them 
happy, no matter what we do, and trying to will consume so much energy 
that we will ignore the needs of the remaining 80%.)

> This also means that whatever platform support library you have would 
> include support for xpcshell/xpconnect/whatever else is being used by 
> Gecko as a base layer.

I don't understand. XPCOM is slated to be killed in Gecko in the long 
term, it's one of the technologies we need to get away from. Thunderbird 
on Android is not going to use XPCOM, nor a compat layer emulating 
XPCOM, but a pure JS module system.

If things are backported from the new implementation into old 
Thunderbird, TB can use it on the pure JS level. Or build a small XPCOM 
wrapper in JS, if absolutely necessary.

> I believe that it would be fairly easy to replace the address book, 
> import, mime, and compose code

heh! I agree that these are components that would be easiest in a 
relative sense. But not easy in an absolute sense. "Fairly easy" is 
quite a statement. :) You of all people should know how hard it is to 
replace libmime, within existing Thunderbird.

> replacing the account implementations and associated frontend bits 
> (e.g., nsMsgDBView) is probably so difficult it's not worth 
> attempting. Accordingly, to me, there seems to me to be little reason 
> not to throw some people at porting over the first few bits rapidly.

Right!

I think you're actually saying here that you agree with my approach. 
Because the conclusion is that a gradual rewrite of Thunderbird, with 
the result of eventually everything being replaced with JS components 
without XPCOM and XUL, is "probably so difficult it's not worth 
attempting". That's precisely what I keep saying! :)

> 3. Paid support, if necessary, would be available to do the porting of 
> bits to Thunderbird.

What do you mean? If you meant that Thunderbird or Mozilla could hire 
people specifically to backport parts of the new implementation to old 
Thunderbird, then yes, I think that would be a great way to distribute 
the work load among several developers.

One way to visualize the problem is the components on the x axis and the 
different tasks for each component on the y axis. Instead of slicing 
work in x axis, you can slice in the y axis. I think that produces much 
better and more homogeneous results, because you use the individual 
talents better. (Of course, you can slice in both directions, too.)

That means: One team builds the new client, another team backports the 
new components to old Thunderbird, and a third team fixes Gecko breakage 
in old Thunderbird. All of these need different skills.

Even within the new client team, we could slice work. In another 
project, I need 10% for the implementation of the client, 10% for the 
server, 40% for tests, and 40% for reviews and landing. If you add 
integration into old Thunderbird on top, numbers look several times 
worse. If we could reduce that overhead (make sure reviews and CI are 
efficient) and slice work horizontally (e.g. let another dev build the 
tests, yet another backport etc.), that would help a lot. Like a factory 
line. A good test suite is independent of the implementation, anyway, 
and can be written even before the component.

> Beyond that, I think the crux of the issue is in the manner of a 
> pitch. Most users aren't going to notice backend changes at all unless 
> it impacts them, but front-end changes tend to engender a lot of 
> complaints.

Agreed! :-)

Luckily, with CSS, we can style the new HTML-based implementation very 
much like the old Thunderbird, so that people will immediately recognize 
it as TB.

I've once reimplemented a C# desktop app as webapp. Not only was it 100 
times faster to load, and 50 times faster to implement, but I could make 
it look almost like the desktop app, using CSS. It was immediately 
recognizable. You can do amazing things with JS and CSS.

So, I don't worry about that part.

> --and in terms of pitch, you don't describe it as being the 
> replacement for Thunderbird.

How would you describe it?


Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170411/715f2f6e/attachment.html>


More information about the tb-planning mailing list