<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<br>
<div id="smartTemplate4-quoteHeader">
<blockquote type="cite" style="margin-bottom: -20px !important;
padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small; padding:1em;
background-color:rgba(220,220,240,0.4); border-radius:3px;"> <b>Subject:</b>
Future Planning: Thunderbird as a Web App<br>
<b>To:</b> Tb-planning <br>
<b>From: </b>Kent James<br>
<b>Sent: </b>Thursday, 17/09/2015 23:03:46 23:03 GMT ST +0100
[Week 37]<br>
</div>
</blockquote>
</div>
<blockquote class=" cite" id="mid_55FB38C2_1090404_caspia_com"
cite="mid:55FB38C2.1090404@caspia.com" type="cite">As we are
discussing our future, both in relation to radical changes
expected in the Mozilla platform, and our need to express where we
are going to potential partners and donors, we need to discuss and
agree on some big-picture issues. One of those was end-to-end
encryption that we discussed recently. I want to discuss here our
future platform, and how it related to users and their needs.
<br>
<br>
tl;dr Thunderbird over the next 3 years needs to convert to being
a web app that can run on any browser that supports ES6 Javascript
and HTML5. (web app does not imply cloud-based, only that the
underlying platform is js/html).
<br>
<br>
There are two independent but both equally critical reasons why we
need to go this direction.
<br>
<br>
First, the Mozilla platform itself has no long-term commitment to
being available as a general-purpose development environment to
run non-browser software, other than as a web app. At the same
time, they are doing amazing innovations to allow more and more
functionality traditionally associated with native clients to run
under the "Web as a Platform" meaning the HTML5/ES6 stack. Really
in the long run we will either have to fork the Mozilla platform
and maintain it ourselves as an email development environment, or
go with the flow and convert. Let's convert.
<br>
</blockquote>
We will have to convince Addon authors to convert away from XUL, so
there needs to be documentation or workshops helping to get away
from this. And obviously we need a transition time where "both"
technologies can be used concurrently to find out about performance
/ compatibility issues. According to the timeline you give below,
there is not much wiggle room there.<br>
<blockquote class=" cite" id="mid_55FB38C2_1090404_caspia_com"
cite="mid:55FB38C2.1090404@caspia.com" type="cite">
<br>
Second, more and more users are using a variety of platforms,
including not only our traditional desktop environments but also
Android and iOS (and other mobile OSes hoping to join them). I'm
writing this message using Thunderbird on a Microsoft Surface 3
Tablet, which can now run traditional Windows applications such as
Thunderbird. But we can't expect most of our users to buy a tablet
from a second-tier operating system, merely to be able to run
Thunderbird (as I did). In the last 24 hours, I have accessed my
email using 4 different devices (Android phone and tablet, Windows
desktop and tablet). Only 2 of those devices can run Thunderbird.
We need to have a serious mobile story. Starting from the existing
forward-thinking Mozilla web environment, we should be in an
excellent position to convert our existing code to ES6-js/HTML5,
and that is the best long-term way to support our users on the
full range of platforms that they expect to use.
<br>
</blockquote>
I am using Android Gmail App to access my email in parallel with the
more comfortable Thenderbird on my desktop when I actually try to
get some work done. Most email providers already allow web access to
their emails. But a unified Thunderbird frontend on Android and
Firefox OS would sure be nice.<br>
<blockquote class=" cite" id="mid_55FB38C2_1090404_caspia_com"
cite="mid:55FB38C2.1090404@caspia.com" type="cite">
<br>
Last year, jcranmer introduced JsMime for some of the mime-related
processing. This year, he is specing a Js database. I am working
on JsAccount that will allow us to create new mailnews accounts
and associated objects (server, folder, URL, protocol, etc.) using
js and interoperate with our existing code. Although initially
aimed at new account types, JsAccount will eventually make it
straightforward to incrementally convert all of those core objects
from C++ to Javascript. We need to plan to convert the entire
backend in a similar nature to ES6 javascript.
<br>
<br>
Looking to a rough long-term schedule, I see future versions of
Thunderbird looking like this:
<br>
<br>
38 (Avocet), 45 (3/2016 Bunting), 52 (01/2017 Cormorant?):
Traditional XUL/C++ app
<br>
<br>
59 (09/2017 Dunlin?) Last and traditional XUL/C++ release. By this
date, a reasonable possibility is that the Mozilla platform will
no longer be usable for non-browser XUL-based development. This
version of Thunderbird, in that case, would need to ship on a fork
of Mozilla from the point where XUL-based development becomes
untenable. </blockquote>
can you elaborate what you mean? Forking would make XUL-based
development impossible? Or XUL based development necessitates
forking?<br>
<blockquote class=" cite" id="mid_55FB38C2_1090404_caspia_com"
cite="mid:55FB38C2.1090404@caspia.com" type="cite">This will also
be our last major XUL-based release, and we will not attempt to
keep current with the new non-XUL Mozilla platform. It would also
be useful to ship a stripped-down version of Thunderbird as a web
app with this release.
<br>
</blockquote>
for the web app, will there be local storage? a "gloda-like"
repository that can be stored on the hard drive? will the data be
cross compatible with any other desktop email clients? <br>
<blockquote class=" cite" id="mid_55FB38C2_1090404_caspia_com"
cite="mid:55FB38C2.1090404@caspia.com" type="cite">
<br>
07/2018 Egret? (no point in matching release numbers to Gecko
anymore): Thunderbird ships a full-version web app.
<br>
<br>
I don't see what choice we reasonably have, given the announced
changes in the Mozilla platform. We should view this as an
opportunity to both get out from the current Mozilla
regression-driven development, to being able to focus on our own
issues. Hoping we can adapt to changes in the Mozilla platform,
with no commitment from Mozilla that they will try to make that
easy, is an enormous risk with little upside for us.
<br>
<br>
Comments?
<br>
</blockquote>
Any plans on who from the Thunderbird team could / would lead
development. Are we going to get some help from the Firefox team? <br>
<br>
<br>
<br>
</body>
</html>