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 agrees HTTP/HTTPS/FTP need to go over IPC, i.e. the content process must not be allowed to open TCP/IP or other network connections. (Will the content process ever need to make DNS requests?)

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.

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.

miscellaneous issues

LoadGroups

LoadGroups presumably live in the content process. What kinds of notifications (cancel events, others?) does they need to get?

Application cache

what's it used for, and how will it play out in e10s?

EventSink listeners

(Firebug, for instance). Will they live in the chrome process and get all notifications there? Will we need to propagate these events to both chrome/content processes?

Suspending channels

when do we do this? Presumably needs IPC.

stub classes

It's not clear yet whether the "stubs" will be separate classes, or whether we'll start by just adding hooks to the existing Channel, etc., classes. I'm planning to start with the latter, since that way I don't have to rip out and dupe existing functionality. But this could get complicated--i.e. if we simply pass along the array of headers from Chrome->Content, we'll need to make sure that any state in the stub channel matches the headers it's been given. There is a lot of state in nsHttpChannel: dozens of member variables. Might make sense to split shared logic into base class, so stub can inherit?

File form POSTs

bz suggested yesterday that we could accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it.

Validating data

Lucas suggested that IPDL parent actors should take measures to validate data passed to them by children, in case the latter have been compromised (ex: validating that strings are actually UTF-16). In necko's case, that should mainly be the URI and other data for the initial request.

Carving work into subprojects

FTP is a great sub-project for someone... Volunteers?

Other sub-projects will probably emerge, but I can't think of them just yet--ideas?

Attendee List

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