This change looks reasonable for me. I hope the client interface to be extracted from ChromeClient to its own. ChromeClient is like a zoo of ifdefs, which modularization effort has aimed to improve. (I don't think we need to split the implementations of ChromeClient: they can implement both interfaces)
On Tue, Jul 10, 2012 at 2:26 PM, Gyuyoung Kim <gyuyoung....@samsung.com> wrote: > Hello folks, > > I wonder whether protocol handler is able to be moved to the modules. I was > told that protocol handler belonges <Current Non-Modules Using Module-Related > Techniques for Loose Coupling> > > == Current Non-Modules Using Module-Related Techniques for Loose Coupling == > devicemotion > deviceoritentation > fileapi > html > notifications > protocolhandler > speechinput > svg > webgl > websql > workers > xml > > <http://lists.webkit.org/pipermail/webkit-dev/2012-February/019628.html> > > However, it seems to me protocol handler is now self-contained except for an > interface which supports port implementation. In intents case, it also has > similar interface in FrameLoaderClient.h. > > Is there any reason that protocol handler can't be moved to the modules ? > > I filed a bug for this and submitted a patch. > https://bugs.webkit.org/show_bug.cgi?id=90766 > > Cheers, > Gyuyoung. > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
