Re: Bootstrapping necko

On 8/11/09 12:20 AM, Jason Duell wrote:

> Right now the TabParent code in dom/ipc forks off a subprocess and sets
> up an IPDL protocol with it.

We need a parent protocol which allows the creation of multiple tabs
(IFrameEmbeddings) and which we can use to hook up other global protocol
state (networking, history, prefs, etc). I've been calling it
ContentProcess.ipdl.

I started on this a while back and got stuck with async constructors. I
think cjones fixed up the async-constructor bit and I'll go resurrect that
work. There will be a singleton/global ContentProcessChild in the content
process which we'll make accessible for it to talk to the parent. For the
moment we'll have a singleton/global ContentProcessParent in the chrome
process also (because we're planning on running all tabs in a single content
process for now). Later we'll end up with multiple ContentProcessParent
(per-domain or using some heuristic similar to what Chromium does).

> 2) I use Chris' Test IPDL code and/or bent's testshell to bootstrap
> necko completely independently of the dom code for now, and rig things
> to init necko requests manually and use printf, etc. to check reply
> content.

I think we also want to make the testshell use ContentProcess, and make
ContentProcess manage a TestShell singleton: that way test scripts will have
the same content-process environment they would actually have in Firefox.

robin_bb posted a patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=507218 which allows client code
(necko) to know whether it's running as the chrome process or the content
process. bent, can you review that?

--BDS

Please send this sort of question to mozilla.dev.tech.dom... there are
lurkers trying to learn how this all fits together and public discussion
will help! followup there please