Confirmed users
431
edits
Necko: Electrolysis design and subprojects: Difference between revisions
Necko: Electrolysis design and subprojects (view source)
Revision as of 23:44, 27 August 2009
, 27 August 2009→Implementation design
| Line 18: | Line 18: | ||
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. | 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. | ||
== General design/architecture issues == | |||
==== stub classes ==== | |||
It's not clear yet when our content "stubs" will be separate classes, or when we'll just add hooks to the existing classes. Will depend on the class. nsHttpChannel will have a separate nsHttpChannelChild class, for instance, but nsIOService may just have if(childProcess) checks. | |||
==== 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, but keep in mind for other IPC exchanges, too. | |||
==== HTTP Headers ==== | ==== HTTP Headers ==== | ||
| Line 60: | Line 68: | ||
How will chrome know which window to pop Auth tab up in when HTTP auth is needed? Right now the Channel has callbacks which can be used to get originating window. We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen. | How will chrome know which window to pop Auth tab up in when HTTP auth is needed? Right now the Channel has callbacks which can be used to get originating window. We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen. | ||
==== File form POSTs ==== | |||
bz suggests that we can 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. | |||
; Channel "owner": What's this frob for? Does setOwner need to propagate across chrome/content? | ; Channel "owner": What's this frob for? Does setOwner need to propagate across chrome/content? | ||