Proposal to start a new implementation of Thunderbird based on web technologies
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Fri Apr 7 21:30:28 UTC 2017
There's been a lot of discussion about this proposal, and I think some
people have modified their opinions or clarified them in ways that
aren't necessarily collected in one place. I think we can come to a
better agreement if we go back and start our positions more clearly.
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" (and I'm leaving it vague on what exact criteria that entails).
To that end, here are some suggestions to the proposal:
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).
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. 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 realize this is something you're likely to disagree with, but I
suspect the disagreement is more over perception than fundamental
semantics. I believe that it would be fairly easy to replace the address
book, import, mime, and compose code; that replacing the search and
protocol implementations are probably doable (with SMTP being easiest
and IMAP hardest); that replacing the database is challenging, but
possible if you look to only implement a well-defined new DB API that
coexists with the old one but doesn't eliminate it; and that 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.
3. This may be controversial, but I suspect it's less controversial than
it seems. Paid support, if necessary, would be available to do the
porting of bits to Thunderbird. I'm sure we disagree on where the line
should be drawn, but I'm not proposing that everything would be
considered a viable candidate (i.e., I'm fine with you objecting to
having to port nsMsgDBView-replacement), and I suspect you're open to
letting mostly standalone stuff get done (e.g., the address book). So
I'm happy if we can both agree that a line should be drawn, it should be
drawn somewhere in the middle, and we can agree to defer the discussion
of where it should be drawn until an actual relevant case comes up. The
question of who is paid to do so is also something that I'm fine with a
fuzzy answer.
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. 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--and in terms of pitch,
you don't describe it as being the replacement for Thunderbird. It's
also clear that, unlike Firefox, the UI of Thunderbird cannot be easily
decoupled from its backend, and as to how to deal with that... I have no
opinion; I'm a backend guy through-and-through.
I would also suggest an effective mandate that developers on the new
project should be sensitive to disruption to Thunderbird UI (if the
intent is to replace the UI of Thunderbird with new UI). As well, they
should also have explicit mandates to have better testing infrastructure
and documentation than Thunderbird has traditionally maintained,
including performance tests (as a rough baseline, the question should be
"how well do we perform on a 1M message folder?"--and yes, I'm aware
that Thunderbird doesn't look good on that regard right now). I also
think that the testing infrastructure should be shared with TB as much
as practicable--e.g., sharing the same datasets for performance tests.
How does that sound?
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning
mailing list