Confirmed users
591
edits
Thunderbird/NextGeneration/Motivation: Difference between revisions
Thunderbird/NextGeneration/Motivation (view source)
Revision as of 19:53, 14 January 2018
, 14 January 2018Expand on gradual change being costly
(Motivation - moved from start page) |
(Expand on gradual change being costly) |
||
| Line 7: | Line 7: | ||
What's really making this change required, though, is that the Mozilla platform moves away from XUL and XPCOM towards HTML and Servo. Both XUL and XPCOM are base technologies that Thunderbird is written in or that define core parts of it. The Thunderbird project already uses a good part of its development effort just keeping up with Mozilla changes, and this effort is going to increase significantly in the near future (Nov 2017) when XUL extensions are dis commissioned. Mozilla made this drastic move not to deliberately kill a community, but to allow them to make large changes to the platform. These very changes are going to affect Thunderbird massively, being the largest XUL and XPCOM application ever written, even bigger than Firefox itself. | What's really making this change required, though, is that the Mozilla platform moves away from XUL and XPCOM towards HTML and Servo. Both XUL and XPCOM are base technologies that Thunderbird is written in or that define core parts of it. The Thunderbird project already uses a good part of its development effort just keeping up with Mozilla changes, and this effort is going to increase significantly in the near future (Nov 2017) when XUL extensions are dis commissioned. Mozilla made this drastic move not to deliberately kill a community, but to allow them to make large changes to the platform. These very changes are going to affect Thunderbird massively, being the largest XUL and XPCOM application ever written, even bigger than Firefox itself. | ||
This means that large parts of the codebase have to be rewritten anyway, in the mid-term to near future. The TB:NG project proposes to use this opportunity to also create clear component separation and clean API that make it easy to learn the codebase and easy to make changes to it. A good extension API surface and more stable extensions would be a side effect of a good internal API. | This means that large parts of the codebase have to be rewritten anyway, in the mid-term to near future. Of course, the changes in Gecko are gradual, but eventually, the technology will go away, so the overall work is there nonetheless. | ||
Given that XPCOM is the very technology that creates the API between the modules, is hard to replace step by step. I think we would spent as much time integrating the new modules with the old code as we would take writing the module in the first place, which means the overall effort increases at least 2-fold by trying to do it step by step. Worse, the new component would have to adhere to old and unfortunate design patterns that emerged between components. | |||
The TB:NG project proposes to use this opportunity to also create clear component separation and clean API that make it easy to learn the codebase and easy to make changes to it. A good extension API surface and more stable extensions would be a side effect of a good internal API. | |||