Proposal to start a new implementation of Thunderbird based on web technologies

The Wanderer wanderer at fastmail.fm
Wed Apr 12 14:04:01 UTC 2017


Sorry for responding so relatively late to the original mail; I've been
distracted by other things, and only just read through the thread today.

Most of the discussion thus far seems to have been about the proposal to
reimplement in broad terms, and that's probably as it should be.
However, I'd like to respond to a couple of the more detailed
possibilities brought up in the original proposal mail.

For what it's worth, I approve of the idea of rewriting from scratch
with the aim of UI equivalence and feature parity (within reasonable
limits, although reasonable people may disagree where those limits are),
but I also have serious reservations (which I think I read Joshua
Cranmer as sharing) about whether there is even any plausible hope of
having sufficient manpower available to staff the various "teams" Ben
has suggested to effective levels.

(For the record, I'm 99% an interested user, although I've made a couple
of comparatively minor contributions to Thunderbird in the past - in the
form of code patches, not money - and am not inherently averse to making
more in the future.)

On 2017-03-24 at 13:04, Ben Bucksch wrote:

> Deeper goes the problem of  virtual folders. Thunderbird has them
> implemented as a bolt-on, which essentially keeps a copy of the
> mails, as far as I understand, and they are slow and inflexible. A
> new Thunderbird implementation could take an approach of where
> folders are a view that is computed in real time (like views in
> databases). This matches what GMail does with the AllMails folder and
> tags as properties, and then tags also form a virtual folder. There
> are important implications that this has: I can have a unified inbox,
> one inbox per folder, and I can have the emails sorted into specific
> project folders on arrival, all without overhead. The same incoming
> email appears in all 3 folders in the same second, and is marked read
> at the same time. I no longer have to move emails, but they are
> filtered.

The mention of GMail-like views leaves me cautious. Is this related to
what GMail does with message deduplication (only store one copy of the
message, and display it in multiple locations), or is it something
different and more folder-centric rather than message-centric?

If the latter, this is probably fine, but the former could be
problematic. So far as I can tell / am aware, Gmail appears to do its
message-level deduplication by treating messages with the same
Message-ID as being identical and discarding any duplicates, even though
in some cases (e.g. sending an E-mail to a mailing list and then
receiving a list-modified copy back to yourself) the second message with
the same Message-ID may in fact include important differences.

I consider that a distinct misfeature, and would not be at all pleased
to see it replicated in Thunderbird, or in a successor. (I also
occasionally _want_ to mark one copy of a message read while leaving
another marked as unread, e.g. when I've been CCed directly on a message
which was also sent to a mailing list to which I subscribe.)

Assuming that sort of issue (the question of what criteria to use to
determine message uniqueness) can be addressed, however, I approve of
this concept.

> 0.8. Be close to the existing Thunderbird
> 
> Even though we write almost all code from scratch, we will save a lot
> of time by having a clear goal: We want to replicate the current
> Thunderbird, from an end user perspective. That means, the user will
> find the same 3-pane window layout, the same way how folders and
> message lists and the thread pane operate. The theme will be similar.
> Existing Thunderbird users should feel right at home.
> 
> We retain the overall UI and most features and qualities like 
> performance, even if we do not copy all little details.

What about those of us who prefer a Thunderbird UI more like that which
came *before* "current Thunderbird", and apply various hacks (add-ons,
userChrome.css, et cetera) to restore aspects of that UI? That is, those
who may have felt "right at home" in a previous Thunderbird version, and
felt that a later version took that home away from them.

Will this rewrite take those people into account, and either provide
options for such UI variations, or make sure that it remains feasible to
hack the UI locally (by whatever means) to achieve that result?

(Examples fall into at least two categories: modifications which are
possible in current Thunderbird, and ones which are not. Examples of the
former which I change for my own Thunderbird include the To/CC portion
of the compose UI, and zebra-striping of the message list / thread pane;
examples of the latter which I would change if I could include the use
of tabs vs. the use of separate windows.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170412/2e7e72c4/attachment.sig>


More information about the tb-planning mailing list