Necko: Electrolysis design and subprojects: Difference between revisions

Necko: Electrolysis design and subprojects (view source)

Revision as of 21:16, 27 August 2009

2 bytes added , 27 August 2009

→‎Implementation design

Jduell

Confirmed users

431

edits

@@ Line 17: / Line 17: @@
 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.
+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.
-;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 Headers ====
+HTTP headers will need to be parsed first in the chrome process--so things like auth, cache directives, cookies, etc., can be handled.  We will also need to provide some or all headers to the content process, probably via serializing them over IPDL.
+* bz suggests we "whitelist" the headers and provide only needed headers to the content process.
+==== 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 are also listeners that are notified of redirects, and have the ability to cancel if they don't approve (plugins such as flash use this).
+** Right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree.
-====miscellaneous issues====
 ; LoadGroups:  LoadGroups presumably live in the content process.  What kinds of notifications (cancel events, others?) does they need to get?