Confirmed users
431
edits
Necko: Electrolysis design and subprojects: Difference between revisions
Jump to navigation
Jump to search
Necko: Electrolysis design and subprojects (view source)
Revision as of 23:31, 27 August 2009
, 27 August 2009→HTTP redirects
| Line 29: | Line 29: | ||
** There will be listeners that need to notified in both chrome and content processes, so use IPC. | ** There will be listeners that need to notified in both chrome and content processes, so use IPC. | ||
** But right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree, before trying to implement with IPC. | ** But right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree, before trying to implement with IPC. | ||
*** We should feel free to break existing necko APIs here (and in general) if it makes life easier. | |||
==== HTTPS ==== | |||
e10s will hopefully not need any mods for HTTPS. | |||
* One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel. Shouldn't need to actually read security info--see what exactly is needed. | |||
==== LoadGroups ==== | |||
LoadGroups will live in the content process. | |||
* They need to be able to cancel Channels, which should be fairly trivial IPC. | |||
* When Channels are added to a LoadGroup notifications must be sent, both to DocShell (in content) and various listeners in chrome. Right now these notifications are SYNC, but we might want to change them to asynchronous to make them play better in the e10s model. But for now bz/bsmedberg suggest we wait. | |||
* We will need to keep track (via LoadGroups or otherwise) of which channels are "owned" by which content processes, so if one dies, we know to cancel it's requests. | |||
==== Application cache ==== | |||
The application cache is fairly recent & is used for offline mode for web apps like gmail. Unlike the regular HTTP cache, which will be invisible effectively to the content process, the app cache will be visible to the content process, which needs among other things to parse HTTP headers to see if data needs to be cached. | |||
* Presumably cache lives in chrome, and content processes read from it? Not sure. | |||
* This isn't getting lots of use yet, so it doesn't need to work immediately. | |||
* Honza Bambas and/or Doug Camp (ex-Mozilla) are the ones to ask about this code. | |||
; EventSink listeners: (Firebug, for instance). | ; 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: when do we do this? Presumably needs IPC. | ||