It depends a little on what you want to do. Do you want to embed the entire UI, tab strip and all, or do you want to embed web views? It sounds a little from your description that you're reinventing the multiprocess wheel--you can already invoke a renderer process and talk it via an IPC channel--with the container application responsible for resource loading etc. A COM control that just launched a renderer directly seems simpler than adding a COM server in the full app that just short-circuits most of the app :-).
Rather than focusing on a particular mechanism, what do you want the user (or developer) to see? --Amanda On Fri, Nov 14, 2008 at 10:44 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > On Fri, Nov 14, 2008 at 1:44 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: >> >> Marshall Greenblatt <[EMAIL PROTECTED]> wrote: >> > I think it would be nice to leverage chromium's multi-process >> > architecture >> > in a COM context. The chromium browser process would be hosted in >> > a local COM server executable. >> > Each browser window requested by the container >> > application (and created by the COM server) would be a separate webcore >> > process managed by the browser process... >> > The COM runtime could transparently handle LRPC marshaling between >> > the container application and the COM browser process, and the browser >> > process could communicate with the webcore process using IPC per >> > the usual methods. >> >> Sounds good-ish to me. Go forth and code a demo...? > > I think we need to discuss our options a bit more first :-). > > The most interesting implementation may be retrofitting the existing > chrome.exe with COM server support. COM uses command-line arguments to tell > an executable that it's being launched as a COM server. We would modify > WinMain() to look for those command-line arguments and then call various COM > functions to register itself with the system. We would launch the message > loop and either hide or avoid creating the main Chrome browser window (using > a technique similar to background browser tasks, perhaps?). > > The container application would load a simple in-process DLL hosting a COM > ActiveX control. The ActiveX control would internally establish and > maintain a connection with the browser COM server. Each webcore window > (browser control) would perhaps be treated like a pop-up window by the > browser process, with the ActiveX control taking the place of the dialog > frame. Finally, we would create interfaces that hook into various system > capabilities allowing the container application to control browsing, > resource access, context menus, etc. > > This implementation would give embedded browser controls access to existing > Chrome browser functionality with minimal development and maintenance cost. > Does anyone have objections to adding COM capabilities in chrome.exe vs > creating a completely separate executable? > > Regards, > Marshall > > > > -- --Amanda "Knowing when to optimize is as important as knowing how." --Tom Neff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
