Hi M-A, On Mon, Nov 17, 2008 at 3:04 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:
> > To add to Amanda's email (I wrote it at the same time) > > You seem overly cautious of saying that you don't want to creating > anything that would compete with Chromium or Google Chrome. Keep in > mind that we actually don't really care. Otherwise, the sources > wouldn't be under BSD license. I'm glad to see that this isn't an issue. I would hate for you, or anyone else, to choose not to support my efforts simply because you misunderstood my intentions. I've gotten a lot good feedback from you in the past, and I'm hoping for a lot more in the future as well :-). > > > Be warned that as in most open source projects, a lot of people talk > and not many contribute. Don't be too optimistic on third party > effort. I mean, if you want something to be done, you're better to > schedule as if you would completely write and maintain it. Point well taken. > > > You can use the world-writable wiki > http://code.google.com/p/chromium/w/list to store documents. Thank you, I'll look into this. > > > Your design will depend on what you actually want to leverage: the > rendering engine, the multiprocess&sandbox, the basic ui support? At > first you had talked about using the test_shell shim code to implement > something that just works. I think it's a feasible idea but this is > better to just implement RenderViewHost. This time around I'm starting with the approach of "include everything" and then I'll remove the things that aren't actually needed. Even if it ends up eventually being thrown away, it gives me (and hopefully others) a better understanding of browser internals. As a side note, I would not have attempted this project without first implementing the test_shell-based approach, as it provided necessary background knowledge. > > For instance, out-of-process control execution comes "free" from > ActiveX so if you just want to host the browser out of process, you > actually don't need to do anything to achieve that. You just need to > have your interfaces have the attribute oleautomation and the default > marshaler will take care of the plumbing. I don't know how much > experience you have on out of process COM but it's quite easy. As you say, it's quite possible that the IPC-based multi-process component will be redundant. I'll definitely keep my eyes open for a convenient way to discard it during my continued experimentation. > > > Then, if what you want is mostly the rendering engine, simply creating > an "activex port" of webkit would probably do the thing. I'm actually > surprised nobody did that yet. You could probably borrow as much as > you need from the chromium port. > > Then if you want the UI, bookmark&download management (I still wonder > why), etc, then it makes sense to reuse the browser.lib. Bookmark management isn't something I, personally, would want for an embedded client. That will likely be another thing to go by the wayside. > > > 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 -~----------~----~----~----~------~----~------~--~---
