Followup: modularity, WebExtensions, and going faster

[Stuart Philp]

Some assumptions: It's harder to release larger changes than smaller
changes. It's harder to release non-isolated changes than isolated changes.

Potential challenges I can think of:

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.

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.

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.

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.

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).

All fixable problems I think, I like the idea overall

On Thu, Oct 6, 2016 at 12:40 PM, Gregory Szorc <gps at mozilla.com> wrote:

> On Thu, Oct 6, 2016 at 5:08 PM, Benjamin Smedberg <benjamin at smedbergs.us>
> wrote:
>
>> 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.
>>
>> http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-
>> webextensions/
>>
>> 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.
>>
>> 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.
>>
>
> 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.
>
> 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?!
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161006/af38da13/attachment.html>