Followup: modularity, WebExtensions, and going faster

[Bill McCloskey]

I think this is a great idea, Benjamin!

I don't think the async nature of the APIs is necessarily a problem. All
communication with the content process is already async due to e10s.
Somehow we made that work. For UI updates like the location bar/tab strip
thing that Gijs mentioned, I think we could add some simple
transactionality to the APIs.

I'm also not too concerned about the issue of private versus public
interfaces. WebExtensions have a permissions model that would work well
here. Also, dealing with these issues ourselves would probably help to
clarify some of the policy questions around WebExtension Experiments that
have come up recently.

It's true that we probably don't want to expose all our internals through a
WebExtensions API. But we don't have to write 100% of the browser using
WebExtensions. I think Alexandre's experiment with session restore shows
that major parts of the browser could be written this way. We should start
with the easiest stuff and see where we get. Perhaps we'll reach a point of
diminishing returns, but even then we would have made a lot of progress
from where we are now.

-Bill

On Thu, Oct 6, 2016 at 8:08 AM, 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.
>
> --BDS
>
> _______________________________________________
> 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/feeef56b/attachment.html>