<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-text-html" lang="x-unicode">
</div>
<div class="moz-cite-prefix">Hello Joshua,<br>
<br>
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!<br>
<br>
Joshua Cranmer wrote on 4/5/17 7:31 PM:<br>
</div>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">every
estimation for feature implementation I've seen from Mozilla has
been wildly optimistic</blockquote>
<br>
I'm not Mozilla. :-)<br>
I've done rewrites and challenging tasks before, and typically kept
my estimates.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">
<blockquote type="cite"
cite="mid:e1bc5c4f-7d73-1dbe-92db-ea6c74f9c215@beonex.com"> 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.<br>
</blockquote>
<br>
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"<br>
</blockquote>
<br>
Now, we're talking! This is getting somewhere. That's exactly the
concrete level at which we should be talking.<br>
<br>
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.<br>
<br>
There are probably other such low-hanging fruits.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">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).<br>
</blockquote>
<br>
<b>I fully subscribe to this.</b><br>
<br>
We are actually in violent agreement. What you wrote is exactly what
I think as well.<br>
<br>
(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.)<br>
<br>
Later:<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">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</blockquote>
<br>
Yes. And no. It's a balance of how much you backport and where you
focus.<br>
<br>
I think you described it best under point 1. You phrased the balance
exactly as I have it in mind.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com"> 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.</blockquote>
<br>
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.<br>
<br>
(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%.)<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">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.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">I
believe that it would be fairly easy to replace the address book,
import, mime, and compose code</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">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.<br>
</blockquote>
<br>
Right!<br>
<br>
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! :)<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com"> 3. Paid
support, if necessary, would be available to do the porting of
bits to Thunderbird.</blockquote>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com"> 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.</blockquote>
<br>
Agreed! :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, I don't worry about that part.<br>
<br>
<blockquote type="cite"
cite="mid:d9fe8ce7-ccbf-ff5c-d9ad-755162157e57@gmail.com">--and in
terms of pitch, you don't describe it as being the replacement for
Thunderbird.</blockquote>
<br>
How would you describe it?<br>
<br>
<br>
Ben<br>
</body>
</html>