Why change is hard

This is really not the ideal set of interactions between the extension manager and its related components. Unfortunately changing it is going to be hard.

Extension manager inter-dependencies
Extension manager inter-dependencies

Unfortunately adding any new features is also pretty hard until at least some of these dependencies are broken.

3 thoughts on “Why change is hard”

  1. How does the EM depend on the Datastore directly, and how does XPInstall depend on the UI? And the interdependency between the Extensions DB and the UI? (Not sure if this is detailed somewhere, or if it’s easy to explain, but I’m curious and these seem to be the most strange dependencies to me 🙂 )

  2. I think the “Mozilla 2.0” milestone (or whatever is after Firefox 3.6 is being called now) is the perfect time to break things like this. Automated refactoring FTW 🙂

  3. Gijs: Well done, you have identified the main problem points in the diagram. As for your answers, well it’s complicated, the diagram is actually a simplification. Much of the dependency between the EM and the datastore is mostly conceptual in that the EM knows it is dealing with RDF and behaves as such. XPInstall opens the UI when a new download is requested (the UI then tells the EM which then in turns tells XPInstall to start downloading). As for the UI and the DB, the UI is built from an RDF template that simply talks straight to the DB pretty much bypassing the EM component.

    Ian: Why wait? I’d rather do this right now than either suffer dealing with the work and bugs that arise from it for the work we want in 3.6. And I can’t see a way that automated refactoring can help in anyway in a situation like this, there is nothing automatic about changing the ways component interact with each other.

Comments are closed.