Necko: Electrolysis design and subprojects: Difference between revisions

Necko: Electrolysis design and subprojects (view source)

Revision as of 23:37, 27 August 2009

45 bytes removed , 27 August 2009

→‎Application cache

Jduell

Confirmed users

431

edits

@@ Line 47: / Line 47: @@
 * Honza Bambas and/or Doug Camp (ex-Mozilla) are the ones to ask about this code.
-; EventSink listeners: (Firebug, for instance). We'll need to propagate these events to both chrome/content processes, as listeners will live on both.
+==== EventSink listeners ====
+(Firebug, for instance). We'll need to propagate these events to both chrome/content processes, as listeners will live on both.
 * ideally we send one IPC msg per event, not one per remote listener.
 * don't need much data (HTTP/Channel status?); might need to send the data along in the IPC msg.
 * These calls are already async, so no API change should be needed.
-; Suspending channels:  when do we do this? Presumably needs IPC.
+==== Suspending channels ====
+We suspend Channels from the Download manager, and also when plugins don't consume arriving Channel data quickly enough.  Also HTTP auth?
+* We will need to keep around whatever data has arrived but hasn't been delivered, so resume works correctly.  Could happen on either chrome/content end.
-;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?
+==== Http Auth dialog ====
+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 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.