<div dir="ltr"><div>A few very ill-advised comments:<br><br>On Mon, Oct 10, 2016 at 12:50 AM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>We
 are shipping these *today*, and shipping is a tedious and fairly 
high-risk process because we don't have modular isolation or testing.<br></div></div></div></blockquote><br>I
 don't think that modularity is the problem here. 
After all, its very possible to have bugs in systems where every 
component works as specified. (I'd even argue that -- depending on how 
you define "component" -- this is where most bugs occur.)<br><br>On Mon, Oct 10, 2016 at 12:50 AM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But let's say that atomic sync is something that we believe is 
important: I believe we *have to* spend the time to reorganize the 
system so that sync as a module that stores passwords, bookmarks, etc is
 lower/more basic in our module structure, and then we build our 
bookmarks UI, location bar, etc, on top of that core structure. We are 
in charge of designing these things.<br></blockquote><div><br>While this is true, I feel like it misses the larger point. Perhaps I'm projecting my own feelings onto Richard's comment, but the way I interpreted it, atomic sync was just an example of a feature that necessarily crosses module boundaries. I don't think there's any possible way we could possibly enumerate and plan for all of these -- trying to do so would undoubtedly fail.<br><br>And so our choice would be almost exactly the same as it is today: Either we rewrite large parts of Firefox, or we have a low quality implementation of the feature... Except, if anything, the rewrite is even harder, since the boundaries between the modules are even more rigid, and some of them are even on separate shipping schedules... (And while I agree that it's obvious that if we care about the feature, the rewrite is the correct choice, I'm not sure I think that means much.)<br><br>I'm not going to be one to say modularity is bad *per se*, but I don't think it's that clear of a win either. As I see it, you're making a trade-off: you give away flexibility (the ability for anything to poke at anything), and you get 1. some code simplicity and 2. the ability to update modules independently in return.<br><br>The code simplicity is valuable, certainly (and I'll get to this), but the ability to separate modules to the point where they're effectively different products with different shipping schedules is (to steal a point made by rnewman in IRC -- sorry!) possibly the most Conway's Law thing imaginable.<br><br>As for the code simplicity, I'm somewhat skeptical that it would be a real benefit. It seems to me like all that would really happen is that the complexity would be moved to the module boundaries, which is, IMO not where we want it (as I mentioned above, you can still have bugs in a system where every component works as advertised, these bugs are just harder to track down and prevent through testing).<br><br></div><div>Anyway,  it's very possible that I'm being, err, naively negative here (I'm sure there's a better word for this, I simply can't think of it...). I usually try to keep my mouth shut for these discussions, since I'm nigh-undoubtedly the least experienced person commenting here (what with my grand total of ~7 months of hacking on Firefox, and ~7 years programming), but I felt like I needed to say something, despite the fact that I might be missing the bigger picture. <br></div></div>