[webkit-dev] A proposal for "Platform Mechanisms"

[Anders Carlsson]

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 <andersca at apple.com> 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 <darin at chromium.org> 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 <darin at chromium.org> 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 <mjs at apple.com> 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 <ggaren at apple.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100618/e2b092ca/attachment.html>