Hi M-A, Thank you for your questions :-).
On Sat, Nov 15, 2008 at 2:21 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote: > > Have you thought about other possible implementations? We're still very much in the exploratory stage, and so all options are currently on the table. The final solution will need to balance a number of overlapping concerns in order to be feasible from both a usage and development perspective. Here they are, numbered for ease of reference but not necessarily importance. 1. Easy implementation and use by the client-side developer, preferably in the language of their choice. 2. Provide as much browser-like functionality as possible by default. 3. Allow the client to override, customize or disable default functionality if desired [1]. 4. Minimize changes to the existing chromium code base, and avoid duplication of existing functionality if possible. 5. Take advantage of new features, bug fixes and enhancements to chromium while requiring minimal changes to the "embedded component." A nice plus would be delivering the embedded component as part of the normal chromium software distribution channels. That way we can ensure that all users benefit from chromium improvements without embedded clients being left behind (as happened with MS's web browser control). [1] In my experience embedded browser clients generally come in one of two flavors. There are clients who need a viewer with minimal application control and there are clients who need the embedded browser to act as an integrated part of the user interface. The embedded control that I envision would support the first type of client by default while allowing the second type of client whatever level of control they need. Some examples of the advanced interfaces we'll eventually support: A. Security considerations. Allow the client application to set zone permissions and control what type of content can be loaded. B. Resource streams. The client application can intercept or initiate resource load requests and provide in-memory data streams. C. DOM manipulation. The client application can access and manipulate the DOM programmatically. D. Host client plug-ins. Render in-page plug-ins that are actually components belonging to the client application. E. Full JS support. Allow the client to make JS calls to the browser, and visa-versa. > > > - Create a thin activex control that would load chrome.dll and use it > in-process so you could use it mostly unmodified. (You'd need to > integrate some modifications first) Can you provide a bit more information about what changes you foresee needing to make in order to load chrome.dll in-process? > > > - Forget about the browser component and reimplement > RenderProcessHost, RenderViewHost, RenderWidgetHost, etc. Actually, > you don't need this for embedding. The re-implementation is something that I've already done, in a manner similar to the test_shell project. Unfortunately we then loose numbers 2, 4 and 5 in the above requirements list. > You probably just need to split > browser.lib in two and just keep the relevant hosting part. This is something that is likely to happen as we gain a better understanding of what pieces are extraneous for the embedded component. There's no requirement that we use the existing chrome.exe or chrome.dll in the final implementation -- it's just convenient for now. > > > Do you think you would gain much by making it out of process? This is a tough question to answer. I think the major gain is in stability, similar to why chrome hosts tabs and plug-ins in separate processes. If I were an application developer using chrome as the basis for a help system then I wouldn't want my application going down if chrome crashes. After all, help isn't central to the application's main purpose. If, on the other hand, I'm using chrome as the basis for my user interface then a crash in chrome could be fatal for my application irrespective of whether it's in-process or out of process. The final answer to this question will probably come from the implementation side. For instance, if we find significant performance advantages to one approach over the other, or if there's a feature that can only be implemented using a particular approach. > > > M-A 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
