<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/10/2016 16:09, Alexandre poirot
wrote:<br>
</div>
<blockquote
cite="mid:CABCHQ2gvbCh=XiW2KkSUxj3MwPUcygyRtYnCveDrcUmhNdUwjA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<ol>
<li>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?<br>
</li>
</ol>
</div>
</blockquote>
<div>We do have some boundaries with XPCOM, some others with
JSM, yet some others with message managers.<br>
</div>
<div>But that's just too many different kind of
boundaries/interfaces. If we only had one border,
everything would have been much better.<br>
</div>
</div>
</div>
</div>
</blockquote>
I agree with having one type of border between internal and external
code instead of many. I would also be happy to have only 1 border
between different bits of internal code, though I think that's
difficult in practice, mostly because you end up with several
abstraction levels (if we keep using HTML-like things for frontend,
how do you keep CSS for different "modules" separate and isn't that
really a different boundary from the boundaries between your JS,
etc.)<br>
<br>
However, I feel very strongly that we should be using a different
border between add-ons and the browser vs. between different
internal components of the browser. It seems convenient at first to
use the same abstraction, but as David pointed out, this bit (and
still bites) us a lot with XPCOM. You freeze things and then you
can't change anything. If you don't freeze things, add-ons break all
the time. As a simple example: containers/userContextId requires
changes to a lot of the tab/browser "interfaces", as well as some
XPCOM things such as the cookie service. It's hard to insulate
add-ons from that without having 2 separate API layers. Other people
have brought this up before: using your public API layer to
implement your "own" UI/service leads to pain either/both for you
and the consumers of the public API, also on the wider web.<br>
<br>
<blockquote
cite="mid:CABCHQ2gvbCh=XiW2KkSUxj3MwPUcygyRtYnCveDrcUmhNdUwjA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div dir="ltr">If you look, again, at session restore you
will have to go through all of them and it is far from
being obvious and will feel very hard to approach to
anyone except mozilla employees who have to learn all
these things. Web extension abstracts all that. The
difference between a content script and a background page
is very small. <br>
<ol>
<li>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?<span
class="gmail-HOEnZb"><font color="#888888"><br>
</font></span></li>
</ol>
</div>
<div>Session restore?<br>
<a moz-do-not-send="true"
href="http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/">http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/</a><br>
</div>
<div>The big advantage to this particular feature is that it
doesn't involve much UI, which is where WebExtension is
the most limited.<br>
</div>
</div>
</div>
</div>
</blockquote>
... but then, is avoiding the UI problem really going to be helpful
in the future? How do we transition the experience from a
hypothetical successful session restore add-on to other frontend
features if we haven't solved that problem? And, most negatively,
how do we avoid that becoming boundary type number N + 1 (after
XPCOM, JSM, XBL, message managers, system add-ons, ...) that we then
don't get rid of and have to teach every contributor (employee or
volunteer)?<br>
<br>
~ Gijs<br>
</body>
</html>