Followup: modularity, WebExtensions, and going faster

Tue Oct 11 18:22:31 UTC 2016

On 10/10/16 06:50, Benjamin Smedberg wrote:
> Thank you all for the beginnings of a great discussion!
>
> I'd like to follow up on a few points which I think were misunderstood.
>
>   * The focus of my post is about requiring good module boundaries for
>     code that wants to move quickly, and the notion that WebExtensions
>     are the right way to do that. Although I like indulging in talk
>     about making the entire browser modular, that is clearly not
>     something we can accomplish soon. I am talking about the pipeline
>     of development that we're building which starts out with test
>     pilot, through SHIELD studies, to system addons. We are shipping
>     these *today*, and shipping is a tedious and fairly high-risk
>     process because we don't have modular isolation or testing.
>
Looking at the research others have done, it seems that WebExtensions as 
they exist today don't enable the experiments we want to ship today.

To take a different spin on this, we would need code that provides the 
APIs for our experiments, and our experiments, likely to ship in lock step?

This might benefit the shipping process, though I'm curious on the 
details on how in practice.

I'd expect that to be constrained to changes to the WebExtension part 
though, and that in scenarios where the API level needs to iterate, we'd 
be in an environment that's not different to stock firefox code?
>
>   * I also don't think we should limit ourself to WebExtensions as
>     they are today. WebExtensions are purely asynchronous today
>     because of design decisions that Chrome made and we also accept
>     that addons shouldn't be allowed to block the browser UI. That
>     doesn't mean that we can't make API surfaces which are
>     synchronous/blocking, if we feel that's the right tradeoff.
>   * We can make choices about the "stability" of API surface: both
>     APIs we're building internally, and even APIs we expose to addons.
>     I'm going to follow up separately about what I think we should
>     have learned from XPCOM, but if there's anything we should learn
>     it's that frozen API surfaces are often the wrong choice.
>
> We have a stated desire to let certain teams move much more quickly. 
> This includes Hello in the past, it includes a bunch of test pilot and 
> shield studies now, and it will include activity stream work in the 
> future. What I was trying to point out, with a long history of 
> academic research, is that there is a "physics" of software 
> engineering that we cannot avoid: projects and teams move faster when 
> there are fewer modular entanglements, smaller modules in general. We 
> can train new employees and attract new contributors better with 
> smaller boundaries around the code that they have to understand to be 
> productive, and better documentation aout where the boundaries are.
I agree that for problem statements that like constrained modularity, 
building that modularity out and building upon it is going to help the 
software development process.

Building upon your choice of "physics", I think that this model does 
have a limited problem space to which it can be applied to. Similar to 
Newtonian Mechanics, say.

We're probably not good enough yet on taking advantage of the places 
where the model works.

That said, I don't think that we can categorically assert that the model 
applies to a problems statement at hand.

That'd be more a math problem than a physics model.

Axel
> Richard is right that if we try to "remodularize" around our existing 
> infrastructure, some things are going to be really hard. It's 
> basically impossible to provide atomic sync with things designed the 
> way they are. But let's say that atomic sync is something that we 
> believe is important: I believe we *have to* spend the time to 
> reorganize the system so that sync as a module that stores passwords, 
> bookmarks, etc is lower/more basic in our module structure, and then 
> we build our bookmarks UI, location bar, etc, on top of that core 
> structure. We are in charge of designing these things.
>
> We always *have* a structure. I believe that currently we have a 
> structure where Firefox is a large monolith which is very difficult to 
> change effectively. To change that, we don't need to and shouldn't 
> rewrite it all. But we should start carving off pieces so that they 
> are smaller and have real boundaries. I believe we should start with 
> the things which are trying to move faster right now. Maybe we should 
> also start at the other end with core infrastructure like sync. If we 
> carefully carve off pieces, keeping a longer-term vision in mind, we 
> will end up in a place where there either is no monolithic center, or 
> we carved it down enough that we can document/understand/hack on it 
> more easily.
>
> --BDS
>
>
>
> On Thu, Oct 6, 2016 at 11:08 AM, Benjamin Smedberg 
> <benjamin at smedbergs.us <mailto: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/
>     <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/20161011/0f413679/attachment.html>