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

[Maciej Stachowiak]

On Jun 17, 2010, at 11:26 AM, Geoffrey Garen wrote:

>> I propose that we create an abstract class, "PlatformMechanism" which acts as the starting point for accessing such functionality, something like:
>> 
>> class PlatformMechanism {
>>  virtual ClipboardMechanism* clipboardMechanism() = 0;
>>  virtual FileAccessMechanism* fileAccessMechanism() = 0;
>>  virtual PluginMechanism* pluginMechanism() = 0;
>> };
> 
> I think this would read better if you just got rid of the "Mechanism" suffix. It's such an abstract word that it's maybe meaningless.
> 
> You might still need something to distinguish this kind of clipboard from, say, the WebCore clipboard. For that, I suggest using the word "platform."

I agree that Mechanism is a very vague word. Platform is an interesting idea, but I believe it is potentially confusing in some ways. We have normally used platform/ to refer to stuff in the Platform directory. In fact we already have a Clipboard class in WebCore/platform, the role of which is platform abstraction of the underlying implementation. The proposed PlatformClipboard object would not primarily be providing platform abstraction, rather its main role is to provide runtime switchability among different implementations, one of which is a cross-process proxy and the other of which implements clipboard functionality directly. I don't think the name PlatformClipboard clearly identifies how the role is different from Clipboard, given the context of the project.

Cracking my Design Patterns book (or at least my memory of it), another idea that comes up is "Strategy". Strategy is a design pattern where you have a runtime switchable object that provides alternative approaches to providing the same functionality. Then we would have:

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.

Then Clipboard makes use of an abstract ClipboardStrategy, without having to know which implementation it is using under the covers. And ClipboardProxyStrategy could even be implemented using ClipboardDirectStrategy on the other side of the proxy.

I'm not sure if that is the best naming, but I often find the Design Patterns book helpful for naming classes that have an abstract role which is hard to describe succinctly.

Regards,
Maciej

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