On Mon, Nov 17, 2008 at 10:19 AM, Marshall Greenblatt <[EMAIL PROTECTED]> wrote: > Hi M-A, > > We all know that development issues can become emotional for those closely > involved with them. Lets all please make an extra effort not to assume the > worst about other people's intentions or meanings.
I don't think anyone is doing that--we're just trying to figure out what you're trying to do. You keep talking in the abstract, so it's a little hard to follow. > The intent with these comments is to address Ben's stated concerns about > whether the current chrome UI look/feel would be appropriate for an embedded > context. Everyone so far has agreed that it would not. Most people wishing > to utilize the chrome code base have no desire to develop a competing > product. We simply wish to utilize existing chrome capabilities in our > applications without re-implementing them. Hmm. "Everyone," "most people," "we," ... so, are you representing a development team? That hasn't been clear to me--I've been assuming you've been speaking for yourself. What we've had so far (at least on chromium-dev) are a bunch of people asking "so, how could I embed chromium in my application?", along with a variety of suggestions about how to do it (both short-term, using test_shell as a basis, and long-term, where ideas like COM servers have come up). This is all good discussion. > While forking is always an option with an open source project, it is never a > decision to be taken lightly. I maintain hope that we can all peacefully > coexist in the same code base. Well, Chromium is intentionally licensed mostly under a BSD-style license. Anyone really is welcome to do whatever they want with the code (we've already had one complete fork that we're aware of). However, that doesn't mean that anyone's changes will be accepted into the main project--it just means that people or teams that want to take it in a different direction will have to do more of the work to maintain it. I'll note that this is, in effect, how the Chromium team has been functioning relative to WebKit until our recent drive to un-fork, so it's not an unfamiliar approach for us. > Unfortunately, the chrome ActiveX team is a small group of developers with > limited development time and resources. Ah, I hadn't realized that a team had organized around the ActiveX idea. Out of curiosity, what sort of resources have you brought together, and who else is involved? > Re-implementing existing functionality is not currently an option for us. > Modifying the existing browser code base to expose existing functionality is > an option. I hope that the chromium developers and Google are willing to > work with us so that the final solution is beneficial for everybody. We're certainly willing to work with people who have ideas or contributions, but that doesn't mean that we're willing to jump on board the first implementation idea to come by. Chromium already has mechanisms to do much of what you're describing, but embedding more of the browser code has some far-reaching implications--it's not as simple as "wrap a COM server around what's already there". > As you say, IWebBrowser2 would need to be extended. As with any successful > development project we plan to take baby steps the whole way. We have not > committed to supporting IWebBrowser2, but are considering it as a means for > providing a basic level of compatibility with existing clients. If we > choose to go with IWebBrowser2 then we will extend its capabilities only at > the appropriate time. Have you set up a wiki or something with some of these ideas/decisions/etc. that we could take a look at? That might help. --Amanda --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
