Followup: modularity, WebExtensions, and going faster

[Brunoais]

I Agree with gijs (quoted e-mail).

I think that the interface for addons should be different from the 
interface for internal use. The internal code should not become frozen 
due to addons using them. Instead, market research should be done to 
know what addons are trying to do and then create API that lasts about 
as long as the functionality it is abstracting.
If the functionality disappears, kill the API. If the functionality 
fundamentally changes, deprecate stuff and make adjusted API for the 
changes.

WebExtensions is a good base for a stable API for extensions but it is a 
really bad API for the browser itself. On the other hand, XPCOM / XPID, 
with some cleanup and less general objects seem like a good way to 
continue for internal use (not for extensions).

Then there's what addons/extensions require and WebExtensions do not 
provide. I think that also should be addressed.


On 12-10-2016 16:13, Gijs Kruitbosch wrote:
> On 12/10/2016 15:53, David Teller wrote:
>>
>> On 12/10/16 16:45, Mike Conley wrote:
>>> I'm trying to synthesize what I've read in this thread. I'm focusing
>>> more on the modularity subject, and less on things like tools for
>>> ensuring type-correctness or anything like that.
>>>
>>> Here's what I'm reading:
>>>
>>>   1. It might be worth considering re-implementing some browser
>>>      components using WebExtensions. This would likely involve adding
>>>      new, probably privileged APIs.
>>>   2. The current set of modules, as they're defined, may not be optimal
>>>      these days. rnewman brought up a few examples of where our current
>>>      module definitions / boundaries hurt us, confuse things, and / or
>>>      slow us down (Satchel and Password Manager was one such example).
>> There is also a discussion on whether we should base our "new" modules
>> on WebExtensions on something else.
>>
>> So far, I have seen some suggestions of using Rust as a "something
>> else", but I believe that this is something of an implementation detail
>> at that stage.
>>
>>> Here are my thoughts. Hopefully I'm not repeating other people here!
>>>
>>>   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?
>> Good question. In my experience, the main issues with XPCOM/XPIDL are as
>> follows:
>>
>> - in practice, we exposed everything as public, something we want to 
>> avoid;
> Right, but this is independent of the technology you use. If we expose 
> the Rust/WebExt stuff to external people (so e.g. add-ons can 
> implement a replacement location bar) then we're still going to have 
> that problem.
>
>> - given the granularity, frozen interfaces was a momentum killer but
>> unfrozen interfaces was an extensions killer;
> Yuuup. Hard decisions are hard.
>
> To me, it felt like webextensions (and before that, the SDK) were an 
> attempt to have a secondary API layer that you used for add-ons, and 
> your own inter-modular-code could be as unfrozen as you liked. This by 
> definition means that you can't/shouldn't use said secondary API layer 
> for your own stuff because then you're back to square 1 where our own 
> code and add-ons share the same API layer and now everybody is sad.
>
>> - also, the resulting types (and error messages) are very 
>> un-JavaScript-ish.
> Our JS bindings for XPCOM could be (have been) better. WebIDL is 
> already better in that respect, but isn't really geared to JS-based 
> *implementations* (rather than consumption) of static/singleton 
> things, which is part of why it's (IMO) underused today in frontend-land.
>
> ~ Gijs
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
> .
>