Followup: modularity, WebExtensions, and going faster

[Axel Hecht]

On 12/10/16 17: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.
> 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.

I have to disagree on this.

XPCOM boundaries are per-instance boundaries, JSM is 
more-clearly-than-xpcom service boundaries, message managers are 
on-change notification boundaries.

Those things are just realities in software design, and need to be 
reflected.

I think it's an element of good software architecture that the 
difference between these three concepts manifests in the APIs in which 
you interact with them.

Axel

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