On Thu, Nov 13, 2008 at 11:42 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > > > > I'm familiar with straight COM C++ and MIDL and can imagine how that might > look, but I don't know enough about the issues with ATL. I've heard some > objections to ATL in the past. > > At any rate, it'd be good to see a more detailed proposal before committing > to anything. In general, I think it could be reasonable for the chromium > repository to be home to other projects derived from the chromium source. >
Ok, let's talk about possible designs :-) 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, similar to how tabs are handled in Chrome. 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. If a webcore process crashes then neither the container application nor the browser process is taken down as a result. We could even use the same "sad tab" graphics (if that's not IP infringement) and allow the webcore process to be reloaded without necessarily requiring intervention from the container application. > > -Darin > Regards, Marshall --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
