What happened to hiring an architect?

Disaster Master disasterlistmanager at gmail.com
Thu Dec 15 17:28:39 UTC 2016


Thanks very much for the time you are taking to discuss these questions
Kent, it is appreciated, but I have some follow-up questions if you
don't mind (no hurry, just when you have time).

On 12/15/2016 11:35 AM, R Kent James <kent at caspia.com> wrote:
> It is really hard for us to predict what mozilla-central is going to do with XUL and the code that supports it. I should probably have listed a fourth option, which is actually I think the path that we are on implicitly, which is 4) continue Thunderbird indefinitely as a XUL/XPCOM app, forking Gecko at the point where that is no longer viable under mozilla-central.

I still don't clearly understand the implications of this.

If the choice is a forked Gecko, how does that impact Thunderbird,
bottom line?

Is it security? If so, is the most important issue security with respect
to the rendering of HTML emails?

If so, I would think a way could be found to simply limit the
capabilities of said rendering, and strictly forbid anything that could
be a real security risk.

First thing I'd do is eliminate the ability to 'open a web page in a
Thunderbird tab' - just have TB open the page in the OS' default web
browser (or a defined web browser of choice).

Would that really be that difficult or impossible of a task?

> If we do nothing, that is the future. And that is probably the future that many people want. A year ago I predicted that about now we would be no longer be able to maintain day-to-day compatibility with mozilla-central, forcing us into resyncing with Gecko periodically, and that at the point of the next major release (59?) we would have to fork Gecko. In hindsight I was overly pessimistic about the timing, but I still think that is the path we are on. That is a path to a slowly dying Thunderbird.

Can you elaborate on this? Why would this necessarily be the case? If TB
really is nearly feature complete, as many of us believe, why would it
be a bad thing to just focus on bug fixing, and rewriting aspects that
need it (Address Book, Composer, etc)?

> If that is what our donors want, then we'll have to think really hard about whether that is how we should spend their money, but for me as a volunteer interested in Thunderbird as a learning opportunity, I have no interest in that.

Well, I think if TB simply forked Gecko at the point where it became
absolutely necessary, that would eliminate the work needed to 'maintain'
Gecko, freeing up resources to focus on rewriting core code that is
sorely needed (see above).

I just don't see the downside to this road, but maybe its because I'm
not a programmer and don't have a clue about the different moving parts.

> As to the future of Thunderbird addons, unlike plans for future Firefox addons, a first-class Thunderbird addon needs to be able to have the full capability of the core program. In the option 2) that is likely to be some sort of code injection, like a restartless addon. Whether we can solve the security issues associated with that is another open question.

But this would also require a completed full rewrite of all of the core
code, right? Something I thought wasn't a viable option right now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161215/676fda07/attachment.html>


More information about the tb-planning mailing list