Necko: Electrolysis design and subprojects

This is a page dedicated to the design issues involved in making necko work under electrolysis (i.e. moving all network traffic to the chrome process, and using IPDL to communicate with the content process(es)).

Which protocols need IPC?

Everyone thinks HTTP/HTTPS/FTP need to go over IPC (i.e. the content process must not be allowed to open TCP/IP connections).

bz and jst give me the impression that any protocol that does file I/O should also be using IPC (so, file://, about://, jar://). But bsmedberg disagrees, and says that we'll 1) chroot the content process, so it can't cause trouble even if it's allowed to do file I/O, and 2) handle file:// requests in the chrome process. Discuss.

Everyone agrees that protocols that don't do I/O don't need IPC, i.e. data://, and js://

I'm not sure if we need IPC for resource:// or view-source://. Opinions?

Supporting single-process (and possibly standalone) necko?

Supporting single-process necko

We should be able to support single-process XULRunner clients (such as Thunderbird) which aren't moving to multi-process. I'm planning to surround all IPC logic with #ifdef MOZ_IPC, and if it's not defined things should simply work for single process.

Worth continuing "Standalone" necko?

We allegedly advertise necko as working as a "standalone" component (I'm not sure exactly where the line is here: obviously it needs XPCOM, but possibly not much else). It's not clear how much we care about continuing to support this--we don't seem to have anyone using it this way, but we're currently still diligent about not including references to libdom, etc in the necko code.

Do we want to make any efforts at all to keep necko independent, or should we feel free to shove in refs to DOM things going forward? Right now the main ContentProcess protocol is living in /dom, but this is a very artificial dependency, and we could move it to /ipc if we want to keep necko potentially useable w/o libdom. This ought to enable us to have the current setup (single-process necko that only needs XPCOM), plus a multi-process necko that requires /ipc, xpcom, and chromium, but not libdom.

But it's really not clear that it's worth putting even this much effort in, since no one is using necko this way.

Implementation issues for various protocols

HTTPS

Hopefully nothing special beyond the work needed for HTTP needs to be done for HTTPS to work. Fingers crossed.