News for hackers. Stuff that matters.
Re:Proposal to start a new implementation of Thunderbird bas... by Silhouette on Thursday April 20, 2017 @03:09PM (#14159816)
That makes a lot of sense if we're talking about using Gecko to render the contents of arbitrary HTML emails. However, this proposal seems to be about problems supporting the UI itself and proposing a move to some other JS+HTML rendering system as an alternative. At first glance, that appears to be a separate issue, other than both types of functionality possibly relying on Gecko today and rendering engines being quite large so using two different ones not being desirable.
Re:Proposal to start a new implementation of Thunderbird bas... by jcranmer on Thursday April 20, 2017 @03:16PM (#14159887)
Gecko is actually quite difficult to embed (Mozilla more or less gave up on there existing non-Firefox/Thunderbird embeddings around 2011 or so).

There's a lot of low-level interfaces and design decisions that filter through Thunderbird, for example networking interfaces. Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Re:Proposal to start a new implementation of Thunderbird bas... by Silhouette on Thursday April 20, 2017 @03:59PM (#14160285)
Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Right, but isn't the argument quite a few people are making here that moving to a different UI rendering engine doesn't seem to be obviously justified, given the goals of the project and its current situation? If the architecture is as inter-dependent and non-modular as your comments suggest, wouldn't that make changing significant parts of it even less likely to be successful?

At that kind of level, you might be better putting the whole project into legacy mode with emergency updates only, and just letting it carry on for as long as it's useful and then die of natural causes when the time is right. For the other goals mentioned in the original proposal we were talking about, if there's sufficient interest to support doing that much work then an entirely new project with no baggage at all seems like a safer and more realistic bet.