Confirmed users
596
edits
Thunderbird/NextGeneration/Motivation: Difference between revisions
Jump to navigation
Jump to search
Thunderbird/NextGeneration/Motivation (view source)
Revision as of 19:56, 14 January 2018
, 14 January 20184-fold
(Expand on gradual change being costly) |
(4-fold) |
||
| Line 9: | Line 9: | ||
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. | 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. | 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. Other negative effects add another 2-fold factor, so that it eventually takes 4 times as long to operate "on the open heart" than using the "minimal viable product" approach. 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. | 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. | ||