Confirmed users
431
edits
Necko: Electrolysis design and subprojects: Difference between revisions
Necko: Electrolysis design and subprojects (view source)
Revision as of 15:27, 27 August 2009
, 27 August 2009→Implementation issues for various protocols
| Line 11: | Line 11: | ||
I'm not sure if we need IPC for resource:// or view-source://. Opinions? | I'm not sure if we need IPC for resource:// or view-source://. Opinions? | ||
= Implementation | = 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 == | == HTTP == | ||
== HTTPS == | === HTTPS === | ||
Hopefully nothing special beyond the work needed for HTTP needs to be done for HTTPS to work. Fingers crossed. | Hopefully nothing special beyond the work needed for HTTP needs to be done for HTTPS to work. Fingers crossed. | ||