Followup: modularity, WebExtensions, and going faster

[Gregory Szorc]

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?!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161006/686ac246/attachment.html>