Cross-posting to mozilla.dev.tech.network. The main discussion is on mozilla.dev.tech.dom.
--- So, right now rumor has it that necko is a standalone code component, that can be used w/o firefox (do we have any actual clients using it this way?). I'm guessing we want to keep it that way if possible. But I'm wondering how much our electrolysis (e10s) work is inadvertently entangling necko into relying on the dom and ipdl (and chromium!) codebases, and if we want to take some time to think about what if anything we can do to keep necko independent, or pave the road towards it being independent again at some point, or whether it's just going to be too difficult to be worth it. So far my work (none of which is checked in yet) has the following dependencies: - netwerk/Makefile.in now includes chromium-config.mk - necko code now #includes files generated by ipdl - I'm about to add calls to XRE_GetProcessType(), which will rely on code that's planned to be in nsXULAppAPI.h. This is all enough to cause necko to now be dependent on chromium and libdom. I also suspect that it will be a significant pain in the neck to try to support a version of necko going forward that doesn't have these dependencies--though some could possibly be minimized, and I suppose we could in theory (via #ifdefs) continue supporting a single-process necko that is standalone (but it would definitely be extra work, and maybe a lot of it). More realistic perhaps would be a multi-process version of necko that relies on libchromium and ipdl, but not libdom or XULRunner (but this would require moving ContentProcess.ipdl and friends somewhere besides the dom tree). Anyone have any thoughts on this issue? _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
