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?

Implementation design

Most of necko's logic is going to happen in the chrome process.

• The content process will create URIs and open Channels, but these channels will essentially be stubs that are connected to a real Channel in the chrome process via IPDL.

• When an HTTP request is made, for instance, all the nitty-gritty of socket creation, authentication, SSL, cookies, and caching will be made in the chrome process

• The content process will then be notified with the usual OnStartRequest, OnDataAvailable, and OnStopRequest notifications.

So, the most obvious place for inter-process communication will be AsyncOpen (from content->chrome, to queue the network request) and the various "On..." events back from chrome to the content process.

The unknown question is how much additional IPDL communication will be needed for the common case. OnDataAvailable(), etc., all provide pointers to the Channel servicing the request, which allow client code to potentially do things that require access to the chrome channel. For things involving simple header data, this should not be an issue: the plan is to provide the stub channel with all of the HTTP header data (headers will need to be parsed first in the chrome process--so things like HTTP auth, cache directives, cookies, etc., can be handled--and then the headers will be either re-parsed by the content process, or passed along as a data structure in IPDL); so client code requests to find out Content-Type or other such things should not require IPDL traffic.

For things like HTTP redirects the current architecture shifts out the original channel and replaces it with a channel to the new destination. This will probably require IPDL traffic to tell the content process to do something similar on its end. There may be other occasions where IPDL traffic is needed to keep the content stubs "in sync" with what's happening in chrome necko-land.

HTTP

HTTPS

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

FTP

Probably a great sub-project for someone... Volunteers?

Attendee List

• Jason Duell
• Boris Zbarsky
• Johnny Stenback
• roc
• davidb
• joe