On Jun 17, 2010, at 2:04 PM, Jeremy Orlow wrote: > Overall, looks great!! > > > On Wed, Jun 16, 2010 at 6:05 PM, Anders Carlsson <[email protected]> wrote: > > Also, PlatformMechanism is a Factory, and should be named accordingly. Or > > maybe it's a Source of clients/mechanisms. > > > > Good point, it is a factory. > > Is it a factory? If so, I'd expect it to return PassOwnPtrs rather than *'s. > With *'s I'd expect the class to retain ownership (and destroy them when > it's destroyed). >
Currently I just called the class PlatformPolicies. It is kind of a factory but it will only create singletons that are never intended to be destroyed. > > On Wed, Jun 16, 2010 at 8:34 PM, Darin Fisher <[email protected]> wrote: > 2- This looks a lot like WebKitClient in the Chromium WebKit API, except that > WebKitClient is defined at the API layer and not at the WebCore/platform > layer. Related point: WebCore::ChromiumBridge is just a bunch of static > functions because it seems wasteful to define intermediate virtual functions > at the WebCore level. Note: There is a plan to rename ChromiumBridge to > PlatformBridge because the Android port wishes to share some of the same > infrastructure. There is already a typedef in place. > > I'm pretty sure the solution proposed in this thread would work fine for > Android as well. > Cool! > > On Thu, Jun 17, 2010 at 10:31 AM, Darin Fisher <[email protected]> wrote: > Makes sense. By the way, there are more modules other than WebCore/platform > that will require this kind of separation. WebCore/storage has several > examples of this. Jorlow already modified the LocalStorage implementation to > support this kind of separation. It'd be nice if whatever model is adopted > for WebCore/platform can also be applied to these other modules. (Doesn't > sound like it will be an issue.) > > Note that you only need this if you have multiple renderer/web processes. If > you only have one and aren't doing sandboxing, you don't need anything > special. If you're doing sandboxing you could either use LocalStorage the > way chromium does or you could proxy the raw FS/SQL VFS. (The former would > probably be easier and cleaner.) > > Note that the same should be true of IndexedDB. > In the future we definitely want to be able to use multiple render processes, so designing for that is a good idea. > It's not so much about performance. There's a cognitive cost to having so > many layers. But, given (c) above, I understand that you really don't have a > choice. > > FWIW: I can confirm that the "cognitive cost" of even the existing number of > layers in Chromium is high and surprisingly taxing. It's definitely > something to keep in mind and work to avoid when possible when designing > stuff for WebKit2. > That's a good point and something that we should definitely try to avoid. > On Thu, Jun 17, 2010 at 12:50 PM, Maciej Stachowiak <[email protected]> wrote: > ClipboardStrategy --> abstract class > ClipboardProxyStrategy (or ProxyClipboardStrategy) --> class that provides > the details of clipboard functionality by proxying to a privileged process > ClipboardDirectStrategy --> class that implements clipboard functionality > directly. > > For what it's worth, DOM Storage and IndexedDB uses the following naming > scheme: > > StorageArea -> abstract class > StorageAreaImpl -> actual implementation > StorageAreaProxy -> proxy implementation > > I'm not entirely sure the "Strategy" suffix would make these more usable, but > otherwise it seems to match up with what I've been doing already. > I'm only using the "Strategy" name for the abstract base classes right now. > > On Thu, Jun 17, 2010 at 12:53 PM, Geoffrey Garen <[email protected]> wrote: > > Cracking my Design Patterns book (or at least my memory of it), another > > idea that comes up is "Strategy". > > On IRC, Anders mentioned "Manager" as an alternative to "Strategy". > > I disagree. Manager is such an overloaded/overused word in CS that it has > pretty much no meaning. Strategy is at least unique. (Though I'm not > completely convinced such a suffix is required...especially for the > non-platform code like LocalStorage and IndexedDB.) > Good point. - Anders
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
