Hi Amanda, On Mon, Nov 17, 2008 at 10:48 AM, Amanda Walker <[EMAIL PROTECTED]> wrote:
> > 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. I'm happy to hear that :-). As a resident on multiple message lists I live in constant fear of flame wars, which tend to be the antithesis of productive conversation. > 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. I'm glad that you asked this question. At the moment I'm speaking primarily for myself, but also for other people who have shared with me their ideas and desires for an embedded ActiveX control based on chrome. I've counted 5 so far, but I'll leave it to them to decide if they wish to become active contributors. It's clear from core developer comments, I think, that providing an ActiveX control is not a priority for the core chromium or Google development teams. I've gotten the strong impression that if someone doesn't take advocacy ownership of this issue it will continue to go nowhere -- perhaps it's a false impression. I've volunteered myself for the advocacy job (which I would be happy to give up if someone else would like it), and I've taken steps to begin code-based exploration. My interest here is solely a working browser control based on chrome that satisfies a finite set of design goals (see parent thread). I'm not seeking to write a web browser, as has been suggested, no is my intent to release a product that competes with chrome. As has been mentioned by others, I could more easily fork chrome and develop whatever I choose. However, I prefer an approach that will allow me to contribute my changes back to the chrome project as a whole. I've demonstrated this preference with a number of changes, admittedly small, that I've implemented in the past. I have no expectation that new changes I make will be accepted. I'm positive, however, that they won't be accepted if I don't first make the effort to discuss them with the chromium development team. That is why, up to this point, the discussion has been primarily abstract -- issues this important should not be decided by one individual, especially when that individual (myself) is not intimately familiar with the design choices behind current chromium internals. > > > > 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? The resources brought together so far are: 1 part-time advocate willing to do development (myself), and 5 people providing input. I'm hopeful that as the ActiveX concept is fleshed out more people will contribute ideas and/or code. I'm not asking chromium or Google to commit development resources to this project. I'm simply seeking ideas and feedback on how we can make our changes in a way that would beneficial to the chromium project as a whole. Most of the feedback so far have been along the lines of "use RenderViewHost." Unfortunately, this advice is incompatible with what we're trying to achieve (again, see parent thread). I appreciate the feedback that M-A and others have provided in the past about why certain things are implemented in certain ways. That is the type of feedback that I'm seeking in this discussion. > > > > 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". This is exactly why I'm seeking input at this point in the development process. Again, we need to know about the far-reaching implementation concerns before we go out and write code. Just as an example, I've seen nothing to indicate that I can get (a) multi-process architecture support, (b) printing support or (c) context menus without either accessing the browser base or re-implementing them. Perhaps we don't need or want multi-process architecture support -- let's talk about that. There has been discussion in the past about separating out the printing support -- that would definitely be helpful for everyone. Any guidance that you, or others, can provide that helps move us towards our design goals (again, referring to the parent thread) will be greatly appreciated. > > > > 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. This is a very good idea. Can I add content under http://sites.google.com/a/chromium.org/dev/developers/design-documents<http://sites.google.com/a/chromium.org/dev/developers/design-documents/os-x-interprocess-communication>, or should I look elsewhere? > > > --Amanda 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 -~----------~----~----~----~------~----~------~--~---
