Proposal to start a new implementation of Thunderbird based on web technologies
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Tue Apr 11 02:57:37 UTC 2017
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.
> 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.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning