Allan Sandfeld Jensen
kde at carewolf.com
Wed May 2 16:03:41 PDT 2012
On Wednesday 02 May 2012, Alexis Menard wrote:
> On Wed, May 2, 2012 at 3:12 PM, Dawit A <adawit at kde.org> wrote:
> > On Mon, Apr 30, 2012 at 5:16 AM, Allan Sandfeld Jensen <kde at carewolf.com>
> > 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.
More information about the webkit-qt