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

[Jeremy Orlow]

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).


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.


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.

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.


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.


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.)

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100617/2a3aa8f5/attachment.html>