glodastrophe: the very in-progress experimental desktop front-end to the gaia email backend
asutherland at asutherland.org
Fri Sep 18 05:16:55 UTC 2015
As promised in my other message from the "Future Planning: Thunderbird
as a Web App" thread, I just want to provide some quick pointers and
context for those with some level of interest. This ended up more
wall-of-text than I was hoping, so levity has been injected where possible.
None of this is something you would want to use right now. None of this
is remotely a replacement for Thunderbird. None of this is likely to
ever be a direct replacement for Thunderbird. None of this will not not
not not help with understanding double negatives.
About Gaia / Gaia email:
* Gaia is the name of the Firefox OS UI/UX project. It lives here:
* The gaia email back-end v1 was message-centric because of time
constraints, the expected limited resources of devices, and concerns
over the level of resources services could provide to provide an
acceptable conversation-centric UI.
* We are currently refactoring the gaia email backend to make it
conversations-centric. This means that the back-end fundamentally
thinks about things in terms of conversations. All messages/drafts must
belong to a conversation. (It's possible to show the messages in a
folder on their own, but it would require creating an additional index
and would be unable to leverage storage locality.)
* The back-end was designed based on lessons learned from hacking on
Thunderbird, gloda, improvements to gloda, and the deuxdrop messaging
project. The refactoring builds on lessons learned from the v1 gaia
email backend as well and having time to pay down technical debt.
* Right now the back-end has sync engines for Gmail (leveraging gmail's
conversation logic as exposed to IMAP), Vanilla IMAP (using gloda-style
conversation strict threading logic), ActiveSync (with all messages
living in singleton conversations because of ActiveSync limitations),
and POP3 (using the same gloda-style conversation strict threading logic.)
* ...but the refactoring is still in progress.
* The back-end runs in a DOM Worker and communicates with the front-end
UI over a postMessage-bridge.
* The back-end is offline-first. All manipulations are applied locally
first and then subsequently replayed to the server when we're online, etc.
* I named it! I'm notoriously bad at naming projects! But there is a
joke about gloda in the name if you look for it...
* It's implemented using react.js.
* I've been actively thinking about how to make it feasible for
extensions to replace or augment things. Happily, react.js' encourages
healthy encapsulation and delegation idioms that make this quite natural.
* The gaia email back-end is flux-like in nature in that you request
changes, the back-end applies them locally, then you get events that
propagate through to the front-end so the UI can always reflect the
state of the database.
== Glodastrophe screenshot and code links
Here's a screenshot of what glodastrophe looks like in its "3-pane" mode:
The conversation list is notably an efficient virtual list
implementation that is height-aware and allows random access seeking to
any/all known conversations without having all conversations in memory.
Conversation summaries include up to 3 "tidbits" on unread messages in
* The router for the 3pane is at:
* The conversation list is:
* The actual conversation display widgets in the list:
* The message list is:
* It farms out many things to sub-widgets (which are intended to
potentially be replaced by extensions). They can be found in
* For example, the star widget (which is reused by both messages and
The glodastrophe repo and and active branch is
== Gaia backend code links:
The gaia conversations branch is
Note that there is some dead code in there that has yet to be migrated /
destroyed. Assume anything that looks dumb/ill-advised/you don't like
is dead code that is going away!
API to the front-end:
* The API exposed to the front-end/consumers is rooted by the MailAPI
instance found at
* All of its helper classes/etc live under:
Example sync code:
* This is the steady state sync task of Vanilla IMAP:
* Its documentation is at
* It doesn't actually synchronize the messages itself. It generates
tasks that perform the actual message sync:
* Conversations are actually summary objects derived from the messages
that make them up.
* This logic generates the core state the back-end assumes all consumers
want and which is necessary for core features:
* Front-ends also get to contribute their own logic. The display of
tidbits is a UI decision, including how many to display, so glodastrophe
provides that logic at
(The name "felam" is a play on the Dr. Scholl's "gellin' like a felon"
ad campaign, universally agreed upon as the highpoint of human
television. (We call the mail backend "gelam".))
1: Admittedly, you don't have to look very hard.
More information about the tb-planning