I am excited to see this going forth. It will really open up developers options once this is fully operational. Thanks!
Daniel A. White On Sat, Nov 15, 2008 at 6:55 PM, Marshall Greenblatt <[EMAIL PROTECTED] > wrote: > 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 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 -~----------~----~----~----~------~----~------~--~---
