Followup: modularity, WebExtensions, and going faster

[David Teller]

I would agree that modularity is not the problem – or at least not the
best name for the problem.

In my mind, the problem is that we generally make absolutely no
difference between a private-to-feature API, a private-to-test API, a
private-to-feature-set API, a private-to-firefox API and a public API.

Moreover, our codebase abounds with hidden APIs – for instance, APIs
that are actually accessed through magic observer notifications, through
DOM events, or through magic preferences, or through the category
manager, or by giving magic names to XPCOM components or to some extent
through cross-process messages. Again, these APIs are generally designed
to be private-to-feature or private-to-test but are in practice public.

Oh, and we also have a number of subsystems that are actually
(unspecified, hidden) protocols, rather than simple APIs: things must be
done in a given magic order, otherwise breakage.

Oh, and by the way, most of our APIs don't control their inputs, because
they are initially designed for being private-to-feature or private-to-test.

All this needs to be fixed if we want to be able to compete on feature
implementation speed (and quality) again. Not necessarily today and
certainly not in one stroke, but we definitely need to fix it.


So, here is my list of requirements for any proposal for modularity,
assuming a Go Faster world:

1. we need to be able to implement the APIs in at least JS and Rust;

2. we need to be able to access the APIs in at least JS;

3. we need to plan for the fact that many APIs will eventually be
implemented out-of-thread or out-of-process;

4. clear (and enforced) difference between private-to-feature,
private-to-test, private-to-feature-set, private-to-firefox,
private-to-system-addons and public-to-all-addons;

5. typed APIs with rich types (e.g. not just "Object"/"nsISupports"), à
la WebIDL;

6. no hidden APIs;

7. a clear place for the users of these APIs (including add-on authors,
if they can access these APIs) to request new APIs, more documentation, etc.



There are several ways to fulfill these requirements, which can involve
combinations of platform design, static analysis, instrumentation,
coding conventions and reviews. If WebExtensions fit the bill (or can be
made to fit the bill without breakage), since we are supporting them
regardless, I believe we should go for them.

Cheers,
 David

On 10/10/16 22:58, Thom Chiovoloni wrote:
> A few very ill-advised comments:
> 
> On Mon, Oct 10, 2016 at 12:50 AM, Benjamin Smedberg
> <benjamin at smedbergs.us <mailto:benjamin at smedbergs.us>> wrote:
> 
>     We are shipping these *today*, and shipping is a tedious and fairly
>     high-risk process because we don't have modular isolation or testing.
> 
> 
> I don't think that modularity is the problem here. After all, its very
> possible to have bugs in systems where every component works as
> specified. (I'd even argue that -- depending on how you define
> "component" -- this is where most bugs occur.)