Future Planning: Thunderbird as a Web App

Kent James kent at caspia.com
Fri Sep 18 18:58:33 UTC 2015

On 9/18/2015 6:32 AM, Gervase Markham wrote:
> On 18/09/15 13:55, Mark Banner wrote:
>> Here's my opinion, in no particular order, probably very incomplete:
> I think perhaps I wasn't clear - sorry about that. I wasn't asking "what
> have the mozilla-centrals ever done for us" :-), I was asking "In, say,
> the last two years, what improvements to mozilla-central have been
> useful to Thunderbird, as compensation for the last two years of breakage"?
> To put it another way: "what would we have lost if we had forked m-c two
> years ago"?
> I don't expect the list to be an empty set, but its size and the
> magnitude of the features on it would be useful in determining the
> feasibility of such a step in the future.

For Exquilla, I maintain compatibility with code that is sometimes two 
years old (having only recently dropped support of Thunderbird 24) so I 
have a lot of personal experience with this, both using js and C++. For 
about 2 years it is possible with little workarounds, beyond that it 
gets increasingly difficult. If the code is written to current m-c, it 
is much harder - as even for recent landing of patches to esr38 for code 
Thunderbird code, I had to work around issues of Array.includes 

Examples of workarounds from my code, relative to 2-year old Thunderbird:

1)    Promises.all was not available in Thunderbird 24.
2)    Thunderbird 31 includes critical patches to NTLM management which 
I added to m-c, and without this you can only support a single account 
per server.

Overall these are pretty minor. But as you stretch much past 2 years, 
say to Thunderbird 17, things start to get much, much harder. Also there 
are all of the security fixes, which we (for better or for worse) have 
some exposure to given that we allow full HTML rendering. So forking is 
possible for short periods of time, but long-term is is not really viable.

Also, in my discussion with an experienced outsider (Michael Meeks of 
The Document Foundation), he had this to say after observing our 
situation, which is quite accurate:

"AFAICS your fundamental problem is an engineering / community decision
that doesn't match your resources whereby you run up this steep
travellator trying to keep up with Mozilla changes which ( in theory )
can provide a long-term benefit to make it easier to develop T-bird, but
in doing so you sacrifice actually doing the development on T-bird, so
that future ~never comes =)    Breaking that seems to me to be your top 

I fully agree with that, but I only see two choices: fork and freeze the 
Mozilla platform that we use, or migrate away from it. I am proposing 
the latter.


More information about the tb-planning mailing list