Confirmed users
431
edits
Necko: Electrolysis design and subprojects: Difference between revisions
Necko: Electrolysis design and subprojects (view source)
Revision as of 20:26, 18 August 2009
, 18 August 2009→Which protocols need IPC?
| Line 10: | Line 10: | ||
I'm not sure if we need IPC for resource:// or view-source://. Opinions? | I'm not sure if we need IPC for resource:// or view-source://. Opinions? | ||
= Supporting single-process (and possibly standalone) necko? = | |||
== Supporting single-process necko == | |||
We should be able to support single-process XULRunner clients (such as Thunderbird) which aren't moving to multi-process. I'm planning to surround all IPC logic with #ifdef MOZ_IPC, and if it's not defined things should simply work for single process. | |||
== Worth continuing "Standalone" necko? == | |||
We allegedly advertise necko as working as a "standalone" component (I'm not sure exactly where the line is here: obviously it needs XPCOM, but possibly not much else). It's not clear how much we care about continuing to support this--we don't seem to have anyone using it this way, but we're currently still diligent about not including references to libdom, etc in the necko code. | |||
Do we want to make any efforts at all to keep necko independent, or should we feel free to shove in refs to DOM things going forward? Right now the main ContentProcess protocol is living in /dom, but this is a very artificial dependency, and we could move it to /ipc if we want to keep necko potentially useable w/o libdom. This ought to enable us to have the current setup (single-process necko that only needs XPCOM), plus a multi-process necko that requires /ipc, xpcom, and chromium, but not libdom. | |||
But it's really not clear that it's worth putting even this much effort in, since no one is using necko this way. | |||
= Implementation issues for various protocols = | = Implementation issues for various protocols = | ||