<div dir="ltr">On Thu, Oct 6, 2016 at 5:08 PM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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><div>I spent a week writing a thing about modularity, webextensions, and going faster. I think it's important for us to decide the module structure of our code especially as we start shipping independent modules/going faster. And I believe that having better module structure, boundaries, and documentation is critical to our teams being more agile and also attracting contributors to the project.<br><br><a href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/" target="_blank">http://benjamin.smedbergs.us/b<wbr>log/2016-09-03/modularity-and-<wbr>webextensions/</a><br></div><div><br>I personally think that we should double down on WebExtensions as a model and start using that for large parts of Firefox. But Andy McKay and Rob Helper had some good counter-thoughts and I've asked them to post here to elaborate. <br><br></div>In the post I asked everyone to send followups to firefox-dev, so I wanted to start a thread here to collect responses. Over the next months I'd like this to turn into a firm decision about how we're going to build system addons; but I'd like to start by seeing what feedback people have and even whether I've framed the problem correctly.<br></div></div></div></blockquote><div><br></div><div>I agree with much of what you say in your post, especially the bits around lack of clear boundaries around browser modules. Lots of code has evolved into an unholy mess over the past 10+ years. I like the idea of using WebExtensions as an API upon which we build core browser features. If it's good enough for us, it's good enough for add-on authors and that means add-ons have an opportunity to innovate without having to delve too deeply into low-level internals.<br><br></div><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. There are features like Firefox Sync that put their hands in a lot of cookie jars (not the RFC 2109 kind) and muck around in low-level details that - quite frankly - shouldn't be exposed in any formal API layer. In a WebExtensions world, we'd likely have to expose these things (possibly just to the system add-ons layer) or commit to more stable APIs on the WebExtensions layer. I can see a lot of scenarios where low-level APIs exposed to WebExtensions hamstring future change because of commitment to backwards-compatible APIs. Alternatively, we could see a proliferation of new APIs (e.g. changeFooWidget4()) - and the code behind them - because the existing APIs aren't "just right" and we can't change behavior without breaking backwards compatibility. In short, there is a conflict between system add-ons needing low-level and niche APIs and our desire to maintain stable APIs for 3rd party add-ons. I would appreciate clarification on how exactly these API surfaces will be managed. You allude to this in your post by saying "I think we will have to come up with APIs that are not 
exposed to all addons, but only to particular system addons where we 
understand the risks and experimental nature." So I guess my question is... how? Is there an "ACLs for JS functions" feature that was invented since I stopped doing Firefox frontend programming?!<br></div></div></div></div>