Re: How best to architect the InstallTrigger code to support e10s

Dave Townsend wrote:
> On 3/8/10 14:14, John J Barton wrote:
>> Dave Townsend wrote:
>>> As part of the ongoing extension manager rewrite I'm changing a lot of
>>> the code that makes the InstallTrigger object available to content JS.
>>> As an overview the InstallTrigger object is what websites can use to
>>> test whether XPI installation is enabled and to start extension 
>>> installs.
>>>
>>> The question I have is how to best restructure the code such that when
>>> we move to e10s full on the transition is simple. My best guess would
>>> be something like this:
>>>
>>> An object that implements InstallTrigger that would run in the content
>>> process and talks to an object in the chrome process (initially
>>> directly but presumably later through IPDL).
>>
>> Dave, I don't know what answer you will get, but I'm interested in
>> hearing. Are you implementing InstallTrigger as a "JavaScript global
>> property" in XPCOM categories?
> 
> Yes, mostly the same as it has always been implemented, though I am 
> switching to a pure XPCOM component rather than using a JS helper object 
> as the current implementation does.
> 
>> It seems to me that InstallTrigger need not be synchronous, nor does it
>> need to be part of the chrome process. Ultimately if the user does
>> choose install there are some sync points, but you should be able to
>> open the dialog with the user, download the XPI, and only when you need
>> to restart (or in future trigger the update work) do you need to sync
>> with other processes.
> 
> It certainly doesn't need to besynchronous, but making it fully 
> asynchronous would mean changing the API that websites have been using 
> since back in the Netscape days (the last time we did this, even for 
> bits that were no longer doing anything, we still saw complaints).

Sorry I think I used the words wrong. The InstallTrigger call from the 
page should block the page. But InstallTrigger does not need to lock the 
chrome process or run there.

> 
> I'm pretty sure that the bits of InstallTrigger that actually check 
> whether software installation is enabled does need to be in the chrome 
> process, unless the content processes have access to the preferences and 
> permission manager. Obviously the part that actually starts extension 
> downloads and installs needs to run in the chrome process.

Read access to preferences/permissions should be available without 
blocking in the content process while this data is analyzed.

The download can be done with code in the content process; the only time 
you need to sync with the chrome process is the actual install.

> 
>> If you buy this (and I think this will be common and desirable), then
>> your code needs to be compiled in the content process. Some new solution
>> is needed to say "Javascript global property content-process" vs
>> "Javascript global property application-process".
> 
> I'm not really sure what you've proposed. It's pretty much a given that 
> there has to be a part of this running in the content process and a part 
> in the chrome process I think.

Application-level in-memory data needs to be managed in the chrome 
process. But you don't have to run code that analyzes this data in the 
chrome process. The content process can get a copy.  Think of the the 
chrome process as an http-ish server and the content process as http-ish 
clients. We know that architecture ;-).  Your code GETs the permissions, 
and GETs the preferences and loads the XPI then only after doing all of 
this work independent of the chrome process does it POST the extension 
update.  (I don't mean literally GET, that would be done at a lower 
level, but as a developer you would understand the data synchronization 
model as GET/POST).

jjb