<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 10/10/16 06:50, Benjamin Smedberg wrote:<br>
<blockquote type="cite"
cite="mid:CAK2U7KK9M+8v7dauoUcVDS8V5Xq5Pf60G9OEbckusf2DaNy+UQ@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div>
<div>Thank you all for the beginnings of a great
discussion!<br>
<br>
</div>
I'd like to follow up on a few points which I think were
misunderstood.<br>
<br>
</div>
<ul>
<li>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.<br>
</li>
</ul>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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?<br>
<br>
This might benefit the shipping process, though I'm curious on the
details on how in practice.<br>
<br>
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?<br>
<blockquote type="cite"
cite="mid:CAK2U7KK9M+8v7dauoUcVDS8V5Xq5Pf60G9OEbckusf2DaNy+UQ@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<ul>
<li>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.</li>
<li>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.<br>
</li>
</ul>
</div>
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.<br>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
We're probably not good enough yet on taking advantage of the places
where the model works.<br>
<br>
That said, I don't think that we can categorically assert that the
model applies to a problems statement at hand.<br>
<br>
That'd be more a math problem than a physics model.<br>
<br>
Axel<br>
<blockquote type="cite"
cite="mid:CAK2U7KK9M+8v7dauoUcVDS8V5Xq5Pf60G9OEbckusf2DaNy+UQ@mail.gmail.com">
<div dir="ltr">
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>--BDS<br>
</div>
<div><br>
<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Oct 6, 2016 at 11:08 AM,
Benjamin Smedberg <span dir="ltr"><<a
href="mailto:benjamin@smedbergs.us" target="_blank"
moz-do-not-send="true">benjamin@smedbergs.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>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.<br>
<br>
<a
href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/"
target="_blank" moz-do-not-send="true">http://benjamin.smedbergs.us/<wbr>blog/2016-09-03/modularity-<wbr>and-webextensions/</a><br>
</div>
<div><br>
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. <br>
<br>
</div>
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.<br>
<br>
</div>
--BDS<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>