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

[Joshua Cranmer 🐧]

On 4/10/2017 8:42 PM, Ben Bucksch wrote:
> 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.

I agree that basic implementations of "everything" comes first. Beyond 
that, well, it's best to explain with a hypothetical. Suppose we decided 
that LDAP and QRESYNC support were both necessary final features but not 
earlier mandatory features, and suppose that LDAP were the last feature 
not found in the new address book. I'm saying that we should prioritize 
finishing the LDAP implementation (via FFI to OpenLDAP, say) over 
implementing QRESYNC. Outside of that specific kind of situation, there 
isn't much difference in various approaches, and it's hard to say that 
sort of situation will even come up in the first place. So I'm not going 
to push very hard on this.
>
>> 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.

The problem with JS is that it doesn't have much in the way of the 
standard library. A TCP socket, for example, is handled very differently 
in node.js, in Chromium extensions, in XPCOM, in the B2G bindings, etc. 
At some point, you need a library that presents a common API for all the 
platforms to its different users, much the same way that (say) Rust's 
libstd bridges over i686-linux-gnu, i686-windows-msvc, etc. My point is 
that a) the JS environment of Thunderbird (which I'm referring to as 
xpcshell/xpconnect/whatever) is included as one of the platforms in this 
list and b) it should show up as such in, e.g., a tbpl-like matrix view. 
It is extremely hazy-feely on how this backend works in Thunderbird. (In 
particular, how to handle ES6 modules versus require.js, etc. is not 
something I can recommend a solution to at this moment).
>
>> 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.

The original proposal gave the impression that Thunderbird development 
was to be unfunded, and certainly much of my wording was meant to focus 
on overturning that viewpoint. It matters much less to me who is being 
paid to do what as long as we agree that those acts deserve paid 
developers. Which means we're in total agreement here.
>> --and in terms of pitch, you don't describe it as being the 
>> replacement for Thunderbird.
>
> How would you describe it?

If I had a good example, I would have given it. I'm concerned that being 
upfront with replacing Thunderbird will prime people to bring out the 
pitchforks, but lying obviously helps nobody. So starting out with 
descriptors like "next-generation" or "experimental" or "incubator" that 
are somewhat evasive but not really dishonest probably work better.

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