<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I thought long and hard about this (not even sure I would respond),
but here goes. Sorry for the length, but this includes responses to
everything I felt strongly about in everyone else's responses to
date.<br>
<br>
First, some general comments:<br>
<ul>
<li>I like Thunderbird's current UI, and do not consider it
'outdated' or ugly, but one of the things I love about
Thunderbird (and until Quantum, Firefox) is the ability to
completely transform the UI using both Addons/Themes, and manual
customizations (and I make a lot of these), so...</li>
<ul>
<li> I have no problems with providing (stable, secure) APIs for
people who want to install Themes (or make manual changes) to
'pretty it up' if that makes them happy, but I certainly don't
want developers to waste time on what they may think is
'pretty', because there is simply no way to please everyone.
I want them to focus on providing a stable, secure,
functional, Desktop client, while providing APIs for those
inclined to work on things like 'pretty'</li>
<li>I also have no desire for an Outlook 'clone', but I would
very much like to see the Vertical View made much more robust
(it is not really usable as it stands), as well as eventual
full support for Exchange Protocols<br>
</li>
</ul>
<li>My three primary concerns are security (I was happy to see ba
chime in and let us know that Enigmail/pEp/TB is still a real
possibility), stability and performance, especially when it
comes to 'connected' protocols like IMAP, and hopefully one day
Cal/CardDAV and even better, JMAP - in a Desktop email client. I
abandoned POP long ago, and wouldn't mind if support for it was
completely dropped (although I understand this isn't going to
happen, at least not for a long time)<br>
</li>
<li>As to the 'rewrite from scratch' vs 'rewrite incrementally'
approach...</li>
<ul>
<li>While I'm not a developer, it seems to me that while the
'rewrite from scratch' option may be more appealing to some,
and have some very real advantages, I don't think it is
practical, and would result in utter failure and ultimately a
dying/dead Thunderbird</li>
<li>It seems to me it would make much more sense to hire an
architect with a high level familiarity with the *overall*
code base, and develop a plan for where primary abstraction
layers should be placed (ie, GUI, MailStore, Protocols, etc),
then work on implementing those first</li>
<li>This would likely require writing some kind of automated
test/debug toolkit to specifically capture any/all of the long
forgotten calls that need to be abstracted, but such a tool
would continue to be useful on an ongoing basis I think, so
would not be wasted effort, but would be the basis for the
next-gen debug toolkit for Thunderbird development in general<br>
</li>
<li>Then decisions can be made as to whether or not each primary
layer could be further broken down, then work on those, then
when that part is done<br>
</li>
<li>Start replacing the individual layer components (e.g.,
rewrite the HTML Composer/Rendering component to support a
limited subset of the rendering capabilities of the main web
rendering engines available on the supported platforms - Gecko
(or Quantum), Webkit, EdgeHTML, etc, but start with support
for just the ones needed to work on the 3 major supported
platforms, then support for additional ones can be added as
needed/desired by those willing to do the work<br>
</li>
</ul>
<li>As to a Mobile client...</li>
<ul>
<li>I would use a TB mobile client if it was decent, but I don't
use my phone for email much, only for emergencies and one-offs
- things that can't wait until I get back to my Desktop (or
Laptop), so for me, this should be a low priority, but most
importantly it should not steal focus from the next gen
Thunderbird Desktop</li>
<li>Of course the question be considered when it comes to
technology decisions (like what programming languages to use),
but the answer absolutely should not be based only on whether
or not it supports a future mobile client. If there is a large
trade-off to be made in such decisions, they should be heavily
weighed in favor of the Desktop client</li>
<li>Don't confuse platforms (Desktop, ie Windows, Linux, Mac)
with environments (handheld devices with much smaller screens,
ie tablets, and even smaller, phones). Cross-platform is very
important to me, cross-environment, not so much.</li>
<li>I disagree vehemently with Ben that the primary reason for
TB on Desktop is storing all emails locally. That may be his,
or someone else's, main reason they use it, but I am the exact
opposite. I only use IMAP to access emails on IMAP servers
because I like having a consistent/persistent view of all of
my emails no matter what device I'm using. My primary reason
for TB on Desktop is to have a powerful tool for easily
managing all of my email - multiple Accounts and Identities (I
love TB's Identities support), which is much better done on a
larger screen than it can ever be done on tiny screen.</li>
</ul>
<li>Revenue Generation<br>
</li>
<ul>
<li>In my opinion this is probably the single most important
issue facing TB now, and I am very excited, surprised even, at
Kent's report of current donation levels, so I'll take this
opportunity to put forward an idea (again) I had some time ago
when these discussions first started (I sent it but it never
made it to the list, so I'm assuming it was silently discarded
by one unnamed moderator's kill filter, which I've been in for
a long time now). This would (in my opinion - at least I know
I would fully participate at the recurring level) generate
substantially more revenue, because people would actually be
getting something meaningful in return. Since Thunderbird will
require its own infrastructure sooner or later, why not
develop and provide a:</li>
<ul>
<li>'Thunderbird Hosted Communications Hub' (or whatever you
want to call it), available only to those who choose to
become financial contributors. I would suggest 2 or 3
different levels, e.g.:</li>
<li>One time contributors get a 'Basic' account, one email
address, low storage, no IMAP</li>
<li>Large one time contributors get much more storage,
multiple email addresses and IMAP access</li>
<li>Supporters who opt to provide a certain level of recurring
donations get unlimited storage/email addresses, IMAP
support, with lots of potential for new services to attract
even more supporters:</li>
<ul>
<li>How about a partnership with Timo and the Dovecot guys
to provide the IMAP/JMAP Server support?</li>
<li>Or a partnership with the SOGo team to provide Groupware
(Contacts/Calendars) support?<br>
</li>
<li>Sync capability (see my comment below for details)</li>
<li>Opt-in offerings to help test new/beta features (like
for the hopefully upcoming JMAP support, that Dovecot is
currently working on)</li>
</ul>
<li>One thing: to really make this a compelling offering, I
think it should offer something unique, and I can't think of
anything better than full JMAP support, especially
considering it is intended by nature to be extensible - how
about an extension out of the box that allows you to Sync
everything (including your Profile/Settings) to a server
that supports it (does anyone remember that something
similar was actually possible using LDAP way back in t he
Netscape days?)<br>
</li>
</ul>
<ul>
</ul>
</ul>
</ul>
<p>Ok, now on to specifics...<br>
</p>
> 1. What specific qualities do you like about Thunderbird?<br>
<ul>
<li>Open-Source</li>
<ul>
<li>no one person or company controls it</li>
<li>code is reviewable and modifiable by anyone who knows the
language</li>
<li>I've been using Thunderbird since the very first version
(was it 0.7? or 0.8?), and can't see myself using anything
else</li>
</ul>
<li>Open Standards</li>
<ul>
<li>IMAP support is currently extremely important to me, and
though it is far from perfect, Thunderbird has the best IMAP
support by far of all other email clients I have tried</li>
</ul>
<li>Theme Support</li>
<ul>
<li>meaning specifically, the ability to modify the UI in
substantial ways. While I don't actually use Themes, it is
because of Thunderbird's excellent support for Themes that I'm
able to modify the UI to my liking<br>
</li>
</ul>
<li>Cross platform</li>
<ul>
<li>I work from Windows, Linux and Mac computers, and being able
to use the same application to access my email on all three
makes a tremendous difference in productivity and comfort</li>
</ul>
</ul>
> 2. Where do you see Thunderbird in 10 years?<br>
<ul>
<li>Modular Architecture (without it Thunderbird is dead long
term)<br>
</li>
<ul>
<li>Pluggable Protocol Support</li>
<ul>
<li>It should be easy to add - via an Addon/Extension and/or
to the core code, support for:</li>
<ul>
<li>New/next-generation protocols like JMAP (replacing
IMAP+SMTP, and eventually Cal/CardDAV), and *eventually*
(but not until existing functionality + maybe JMAP
support, is fully replaced and rock solid) others like
Text/Chat (Signal, WhatsApp, and/or even a native
Mozilla/Thunderbird one the service for which is provided
by the 'Thunderbird Communications Platform' referred to
above under my general comments - all properly integrated
with Contacts (the new Address Book rewrite) and Calendars</li>
<li>Pure server-side indexes like those provided by dovecot
eliminating the need for GLODA and the heavy (for some,
unworkable) requirements - ie, must maintain a fully local
copy of all emails for them to be searchable, making it
less than useless for heavy IMAP users with large mail
stores</li>
<li>Server-Side filters (currently Sieve)</li>
<li>Dovecot's Server Side Virtual Folders (Virtual Folders
everywhere, as opposed to Thunderbird's local-only Virtual
Folders (an excellent concept)</li>
<li>Native Sync capability(JSON?) for Contacts/Calendars for
use with the 'Thunderbird Communications Hub', or even
your own server (SFTP/WebDAV?) for security/privacy)<br>
</li>
<li>Modular HTML composer/renderer support</li>
<ul>
<li>instead of reinventing the wheel, just provide hooks
to some of the more popular existing web engines
(Quantum, Blink, EdgeHTML(/Trident?), Webkit), and make
it easy to switch between them should the need ever
arise - or to even strip support for it (HTML rendering
for emails) out completely if desired, reducing
everything to plain text automatically</li>
</ul>
<li>I personally don't use newsgroups, but once the heavy
lifting of making things modular is done, support could be
properly implemented by anyone willing to do the work</li>
</ul>
</ul>
</ul>
<li>Continuing excellent support for Addons/Extensions</li>
<ul>
<li>continue to allow users to make substantial changes to both
the way Thunderbird looks and functions via a stable yet very
capable Addon/Extension API</li>
<li>provide well supported/documented methods and tools for
Addon developers, to help them help Thunderbird in general get
better over time by providing a path for their Addons to
eventually be integrated into the Core code (there would
obviously have to be some well defined meaningful metrics to
decide if/when one would be a good candidate)</li>
</ul>
<li>I hate to say it, but I think it is important enough to
deserve its own bullet...</li>
<ul>
<li>TB-NG should eventually be capable of being a full blown
option for anyone in a Microsoft Exchange/Officer365
environment, including full support for email, Contacts and
Calendars (personal and shared)<br>
</li>
</ul>
</ul>
One point raised by Kent piqued my interest...<br>
<br>
On Thu Feb 01 2018 12:41:09 GMT-0500 (Eastern Standard Time), R Kent
James <a class="moz-txt-link-rfc2396E" href="mailto:kent@caspia.com"><kent@caspia.com></a> wrote:<br>
> Technically, I believe that Universal Javascript has progressed
to the <br>
> point where, if you are going to use a JS/HTML front-end for a
desktop <br>
> app (as we are proposing), then it should be feasible to
separate the <br>
> view from the backend sufficiently that the same views could be
used as <br>
> part of a webmail offering. Look at Fastmail's JMAP as an
attempt at a <br>
> common protocol interface for this, for example.<br>
<br>
I'm not sure how JMAP fits in with the discussion about whether or
not to use JS/HTML for the front end, I would only add that, we
should choose the best tech for a Desktop client. If that choice
comes down to two or three different options, and one of those is a
better choice to support a potential mobile client, then choose that
one. But please, please please do not choose a more limited option
just to make it easier to do a mobile version sometime in the
future. So, I can't offer much more than an evaluation of the
arguments posted in this thread, but Joshua and Henri's arguments
against '100% JS/HTML5' and in favor of Rust for at least the low
level protocol stuff are very compelling<br>
<br>
Lastly, a major question that has been bugging me:<br>
<br>
Not to sound ungrateful, because I'm really not, but... whatever
happened to the 'major financial parting gift' that Mozilla promised
to grant Thunderbird once a financial home was found? This could go
a very long way to getting us enough resources to really and truly
implement the chosen solution, regardless of which direction is
taken - incremental rewrite (my choice) or even a full rewrite from
scratch. So... what happened?<br>
</body>
</html>