Followup: modularity, WebExtensions, and going faster

[David Teller]

On 12/10/16 16:45, Mike Conley wrote:
> I'm trying to synthesize what I've read in this thread. I'm focusing
> more on the modularity subject, and less on things like tools for
> ensuring type-correctness or anything like that.
> 
> Here's what I'm reading:
> 
>  1. It might be worth considering re-implementing some browser
>     components using WebExtensions. This would likely involve adding
>     new, probably privileged APIs.
>  2. The current set of modules, as they're defined, may not be optimal
>     these days. rnewman brought up a few examples of where our current
>     module definitions / boundaries hurt us, confuse things, and / or
>     slow us down (Satchel and Password Manager was one such example).

There is also a discussion on whether we should base our "new" modules
on WebExtensions on something else.

So far, I have seen some suggestions of using Rust as a "something
else", but I believe that this is something of an implementation detail
at that stage.

> Here are my thoughts. Hopefully I'm not repeating other people here!
> 
>  1. XPCOM / XPIDL, for better or worse, offered a boundary and interface
>     system. I think those interfaces were originally intended to be
>     pretty stable. Down the line, I seem to recall us deciding that
>     having frozen interfaces there was slowing us down, and so now those
>     interfaces are changed at will. I understand that we were more
>     constrained because more applications were relying on the underlying
>     interfaces, but this all starts to feel kinda familiar. Are we at
>     risk of creating a new set of interfaces and silos that get holes
>     poked through them over time because they slow us down instead of
>     speeding us up? Are we repeating ourselves? If so, what did we learn
>     last time that will make this time better?

Good question. In my experience, the main issues with XPCOM/XPIDL are as
follows:

- in practice, we exposed everything as public, something we want to avoid;
- given the granularity, frozen interfaces was a momentum killer but
unfrozen interfaces was an extensions killer;
- also, the resulting types (and error messages) are very un-JavaScript-ish.


>  2. Surely we're not the first large application that's had to grapple
>     with this kind of design decision. Are there any success or failure
>     stories from outside of Mozilla that we can draw inspiration or
>     lessons from?

Good question. I don't know of any.

>  3. Is there a browser component that we can experiment with, and
>     attempt re-implementing with the WebExtension API to see how it
>     feels? Or, to take rnewman's angle here, is there an opportunity
>     here to draw some new boundary lines and define a new (but small)
>     WebExtension Thing that combines capabilities from several of our
>     current modules for great good?

Have you looked at ochameau's experiment with WebExtension?

See
http://techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/
and followups.

Cheers,
 David