Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Tue Apr 11 01:42:27 UTC 2017
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
>> 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.)
> 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
(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.
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning