OK, I've got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don't hear any counter proposals, I'll do that.
-atw On Mon, May 25, 2009 at 10:41 PM, John Abd-El-Malek <j...@google.com> wrote: > > > On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow <jor...@chromium.org> wrote: > >> On Fri, May 22, 2009 at 2:25 PM, Drew Wilson <atwil...@google.com> wrote: >> >>> Following up on this, I had a question about the best way to enable the >>> implementation of SharedWorkerRepository to vary for different platforms. >>> I'd like to provide a default WebKit implementation, but on Chromium we'll >>> want to provide an implementation that proxies shared worker operations to >>> the browser process - it is unlikely that the two implementations will share >>> very much (any?) code. >>> >>> The current design just defines SharedWorkerRepository as an interface, >>> then has a platform-specific static factory which returns an instance of >>> this class - the idea is that I'd provide a default WebKit implementation >>> (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that >>> want their own implementation) can provide their own factory method and >>> implementation (for an example of this, see WorkerContextProxy::create() in >>> WebCore/worker/WorkerMessagingProxy.cpp. >>> >>> Is this an acceptable approach? Other approaches I've seen either scatter >>> ifdefs around in header files (see KURL.h for an example) which seems >>> non-ideal for our case which won't have any shared code, or to have separate >>> platform-specific subdirectories, but I'm not certain what the naming >>> convention is for a directory that contains "<implementation for everything >>> but chromium>". >>> >>> I think the interface + static factory approach is the cleanest, >> >> >> This is the gist of what I'm planning for LocalStorage and I believe what >> Michael's planning for AppCache. At least in my case, I think I'll be able >> to share a substantial amount of code by running the backend of the code in >> the chromium browser process. >> > > I also agree this is the cleanest approach. Especially for these kind of > objects (workers, storage) that aren't created or called that frequently, > the memory and performance overhead is negligible. One other benefit is > that it allows platforms to both define their own implementations and to use > the default WebKit implementation. > >> >> >> >>> but I've gotten the impression that the use of virtual functions to vary >>> implementations per-platform is frowned upon in WebKit. Any advice for me? >>> >>> -atw >>> >>> >>> >>> >>> On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen < >>> kenneth.christian...@openbossa.org> wrote: >>> >>>> I believe Qt uses instance() in this situation. >>>> >>>> > Sadly we have not yet found a good verb for the common "get or create" >>>> > idiom. >>>> >>>> Cheers. >>>> Kenneth >>>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev