<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What isn't clear to me is where exactly do we draw the line for API support? It's cool to say that awesomebar, bookmarks, session store, etc are loosely coupled and independently hackable - this sounds great from an ivory tower. But the cobweb of inter-dependencies between all these components exists for a reason: it was/is necessary to implement features.</div></div></div></div></blockquote><div><br></div><div>To echo this: in the past couple of years my opinion is starting to settle that Firefox's vertical component architecture is obsolete in many respects. We very rarely (in my experience, at least) can limit our work to "behind the curtain", wherever that curtain happens to be.</div><div><br></div><div>Speaking very superficially, most of the interesting problems occur between components, much of the rest involves poking at components as if they were bad POJOs, and much of what we can do (and <b>think</b> to do) is limited by the artificial boundaries put in place.</div><div><br></div><div>If we split apart Firefox along its existing lines, we will get more of what we've got, perhaps faster.</div><div><br></div><div>Choosing some different lines will give different results. For example, right now we wouldn't really think to, e.g., up-weight awesomebar results for which we have a saved password, because those two data sources are about as siloed as you can get, and it would be a huge pain in the ass to integrate the two from calling code. At an even greater extreme, implementing decent atomic sync of all browser data sources in the current model is essentially an impossibility, because there's no part of the browser that even pretends to consider them holistically.</div></div><br></div><div class="gmail_extra">My very opinionated position, then, is that putting effort into making Firefox's existing modularity structures "<b>even more so"</b> is not just a waste of time, but actively counterproductive.</div></div>