Updated the names with some feedback from Darin: ProxyResolverV8::JSBindings --> ProxyResolverJSBindings OOPProxyResolverV8 --> IPCProxyResolver OOPProxyResolverV8Host --> IPCProxyResolverHost
So the names are less V8 specific (could drop in a JSC backend on the proxy resolver process-side if you wanted). On Thu, Jul 30, 2009 at 5:03 PM, Evan Martin<[email protected]> wrote: > On Thu, Jul 30, 2009 at 4:20 PM, Eric Roman<[email protected]> wrote: >>> Regarding the class naming in the Out of process design, the convention I've >>> seen most often is to have FooHost classes run in the browser with Foo >>> classes >>> in child processes. >> >> Yeah, I always get confused on which endpoint should be called "Host". >> >> My thinking was from the perspective of the consumer -- the local >> (in-process) component we talk to is named XXX. And then XXX vends the >> functionality of an out-of-process component named XXXHost. (At least >> that is how I always understood the relationship between >> ResourceDispatcher / ResourceDispatcherHost). >> I could be on crack, in which case I will flip the names. > > For renderers, plugins, and child processes in general, "Host" means > the "outer" thing, in an ownership sense, which means the browser > process side of it. I don't know anything about ResourceDispatcher > though. > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
