<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I have a couple of thoughts on this, on three lines:<br>
</p>
<p>XPCOM. We did have extensive contracts and interfaces, strictly
typed and all. My take on the downsides is that we struggled to
create future-proof APIs for one. Also, the implementations of
those had undocumented ranges, bugs, and side effects that callers
depended upon. And some of our APIs never carried fruit.</p>
<p>I also think that tight locking between components isn't as much
about the API between them, but how much of the API surface is
relied upon.</p>
<p>I wonder how other folks see our storyline to deCOM, and how we'd
modularize without the same problem.<br>
</p>
<p>WebExtension compat. If we start exposing internals of Firefox
needed for Firefox development, we'll fork the API space of
WebExtensions. If more browser vendors do so, we'll get into a
game of webcompat for WebExtensions. Not sure if that's helpful
for the extension ecosystem.<br>
</p>
<p>devtools. You quoted devtools as a success story for developing
quickly, and I'd actually say the contrary. We had several years
of experience with js debuggers and debugging, and only then were
able to create an API that was somewhat stable. And even then,
IIRC the entry of FxOS and Android and Chrome debugging still
opened a bunch of challenges. In that sense, I think devtools is a
great example that you can't create good APIs quickly. You need a
lot of experience in the field you're tackling, and then you can
start defining good APIs, and even those still evolve.</p>
<p>Axel<br>
</p>
<br>
<div class="moz-cite-prefix">On 06/10/16 17:08, Benjamin Smedberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK2U7KJTi2Er_xNxi-81Se_OWYDAALGEcSKACRUqs8hGAK2aJw@mail.gmail.com">
<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/"
moz-do-not-send="true">http://benjamin.smedbergs.us/blog/2016-09-03/modularity-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>
<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>