On Wednesday 02 May 2012, Alexis Menard wrote: > On Wed, May 2, 2012 at 3:12 PM, Dawit A <[email protected]> wrote: > > On Mon, Apr 30, 2012 at 5:16 AM, Allan Sandfeld Jensen <[email protected]> > > > > wrote: > >> On Thursday 26 April 2012, Andrea Diamantini wrote: > >> > I did not understand the problem with qt cookiejar. Can you please > >> > elaborate a bit? > >> > >> KDE integrates the KIO and KDE cookie-jar into QtWebKit by setting a > >> custom > >> QNetworkAccessManager and QNetworkCookieJar. > >> > >> The problem is that WebKit trunk now also overloads the default > >> QNetworkCookieJar with one using SQLLite. This overload means the KDE > >> overloaded version is no longer used. > > You're mixing up here. > > QtWebKit with WK2 does it. WK1 stays untouched. > Right, I got that mixed up. A few of the cookie-jar functions still access QSharedCookieJar directly (when the functions doesn't have a document pointer), but I guess that is just a bug in rarely/un- used functions.
> With WK2 the jar sits on the WebProcess so we need to find a way for > the API user to set it's custom cookie jar in the WebProcess. I see > two approaches : plugin or we let the application creating the > WebProcess itself so it can set the cookie jar (we would then just > expose a tiny class to create the WebProcess). > Or a dbus interface :) that was by far the simplest solution for me and kept the WK2 API completely out of the equation. Also the kcookiejar and the webcore has almost 1-1 APIs so the code is much simpler than the existing implementation. But no, I am not sure if it is a good idea in the long run. Best regards `Allan _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
