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.
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. You can use the world-writable wiki http://code.google.com/p/chromium/w/list to store documents. 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. 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. 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. M-A On Mon, Nov 17, 2008 at 3:01 PM, Amanda Walker <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 17, 2008 at 1:48 PM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: >> 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 think it's an incomplete impression. Right now, the core Google > team is focused on getting the Windows version out of beta and getting > the Mac and Linux versions into beta. Anything else is going to be > low priority for a while, but this doesn't mean that that's always > going to be true. This isn't the first time embedding has come up, > and we're quite sincere when we ask some of these questions about > requirements--if you're trying to embed chromium in your app, you have > a much clearer picture of what you need than we do :-). While at > least for the very near term, most of our cycles are on bug fixing and > additional platforms, it doesn't mean we're not quite interested in > what people have to say, or what people implement. > >> 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. > > That's great, and we'd all be very interested to see what those > explorations produce. One thing that many of us are wary of, from > prior experience, is design-by-committee, especially when the > designers aren't also the implementors. A working demo will capture > much more interest than theoretical discussion will, I suspect. > >> 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 I understand that perspective, I also have to say that with this > team, an individual saying "I think we should do X via method Y, and > here's a working proof of concept" get much farther, much faster than > "how should we do X?" Even if the first prototype gets thrown away, a > concrete proof of concept always helps to scope the problem, identify > unexpected complications or side issues, etc. > >> 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). > > Well, it (or the analogous code in test_shell) does seem to be the > closest to IWebBrowser2, and would be a great place to start, since > it's in effect chromium's internal embedding interface. I suspect > that's why people have been pointing you in that direction. > >> 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. > > Fair enough--on the other hand, some of those concerns will be quite > invisible until someone goes out and writes a proof of concept. It's > a balancing act. > >> 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. > > It seems to me that you could get all of those with RenderViewHost, > though you might have to crib a bit. You certainly wouldn't need the > whole browser module, though. > >> This is a very good idea. Can I add content under >> http://sites.google.com/a/chromium.org/dev/developers/design-documents, or >> should I look elsewhere? > > Hmm, that's a good question. I don't know, off hand, but I'll see if > I can find out. > > --Amanda > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
