Followup: modularity, WebExtensions, and going faster

[Gijs Kruitbosch]

On 12/10/2016 16:09, Alexandre poirot wrote:
>
>      1. 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?
>
> We do have some boundaries with XPCOM, some others with JSM, yet some 
> others with message managers.
> But that's just too many different kind of boundaries/interfaces. If 
> we only had one border, everything would have been much better.
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.)

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.

> 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.
>
>  1. 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?
>
> Session restore?
> http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/
> The big advantage to this particular feature is that it doesn't 
> involve much UI, which is where WebExtension is the most limited.
... 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)?

~ Gijs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/4bedbd6c/attachment.html>