[Webkit-unassigned] [Bug 22624] New: [SOUP][GTK] Need API to get SoupSession from WebKit.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=22624

           Summary: [SOUP][GTK] Need API to get SoupSession from WebKit.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: xan.lopez at gmail.com


Soup trunk (2.25.x) has support for persistent cookies now. We need to add some
API/code in order to use that functionality in a WebKit browser:

- First of all, we need a way to get the SoupSession created internally in
WebKit, as that it's the entry point for most actions in libsoup (ie, you need
that to see all the cookie data, for example).
- We need a way to let the user select which backend will be used to persist
the cookies, the existing options at the time of writing being txt and sqlite.
- We need a way to let the user select where will the cookies file be stored.

For the first problem the most straightforward solution is to define a
soup-only getSession() method in ResourceHandle.h, and just use that to return
the session in a public webkit function (webkit_get_soup_session()).

There's many ways to fix the configurability issues. For the backend selection
we could add API to define the SoupSessionFeatures to use, which would also
serve for future bugs/functionality (proxy, http cache, ...).

To set the directory where we want to store our data I guess a reasonable
solution would be to use the XDG Base Directory as default optionally allowing
to override it via an environment variable?

I have a patch that implements the get_session function hardcoding everything
else that I used for testing, I can attach it here if anyone thinks it would be
helpful.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.