<div dir="ltr"><div>Some assumptions: It's harder to release larger changes than 
smaller changes. It's harder to release non-isolated changes than 
isolated changes.<br><br>Potential challenges I can think of:<br><br>1. A much higher 
deployment throughput (multiple small releases vs one large one) 
requires very mature operational methods. We're making strides here, and
 perhaps it would all line over next couple of years, but it's something
 to call out.<br><br>2. Maintaining consistency between APIs. We will 
learn better ways to do things or discover bugs which impact multiple 
APIs, which means multiple APIs need to be updated. A similar bug in 
modules A and B could be fixed, but module C goes unnoticed and pops up 
again in the future. Some modules will lag behind. <br><br>3. Handling 
API inter-dependencies. If your feature relies on multiple API surfaces 
and one of the contracts changes but another doesn't, you can end up 
blocking the feature until all contracts are updated, or force the 
feature to pin to older API versions that can communicate with each 
other which adds some maintenance overhead.<br><br></div><div>4. 
Recreation of environments/builds. Multiple modules revving 
independently means that for testing we need to specify and test 
specific combinations of modules for release. I'm not sure how many 
modules we'd be talking here, but the potential is 100s I'm sure. This 
also affects reproducing bugs to fix issues. A tool to "define" a 
specific configuration (combination of modules) could help (and we 
partially have something like this already I believe?). You also need to
 test both the individual API contracts (relatively easy) and the 
integration of those APIs (harder). You still need to test the end user 
experience as well.<br><br></div><div>5. Where I've seen this in the 
past, managing transactions (and synchronous events) typically requires 
passing IDs around and gets kind of nasty. I'm not sure of the need for 
this within Firefox but I'm sure some modules would have to be done this
 way. Can we do both synchronous and asynchronous APIs (and mark them as
 such)? I would then ask about private vs public APIs (public being 
addon-hackable).<br></div><div><br></div>All fixable problems I think, I like the idea overall</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 6, 2016 at 12:40 PM, Gregory Szorc <span dir="ltr"><<a href="mailto:gps@mozilla.com" target="_blank">gps@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">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></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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></span><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>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>