Necko: Electrolysis design and subprojects: Difference between revisions

Jump to navigation Jump to search
Line 25: Line 25:
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.  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 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.
 
; LoadGroups:  LoadGroups presumably live in the content process.  What kinds of notifications (cancel events, others?) does they need to get?




Confirmed users
431

edits

Navigation menu