[Webkit-unassigned] [Bug 222366] New: [WPE][GTK] Reconsider moving network session APIs to WebKitWebsiteDataManager

[bugzilla-daemon at webkit.org]

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

            Bug ID: 222366
           Summary: [WPE][GTK] Reconsider moving network session APIs to
                    WebKitWebsiteDataManager
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org

r267502 and r267534 moved WebKitWebContext APIs that are internally properties of the NetworkSession from WebKitWebContext to WebKitWebsiteDataManager. This was required since r267763 moved network process ownership from WebProcessPool to WebsiteDataStore. Problem is this doesn't make much sense from an API user perspective. Why should WebKitWebsiteDataManager be the place to configure seemingly-unrelated network properties? I realize it's really late to be reconsidering this now, but if we release these APIs in 2.32 we are stuck with them forever. We still have a bit of time left.

At first, I thought we could keep these APIs in WebKitWebContext and have them internally configure all associated WebsiteDataStores, but it doesn't work. The problem is that a WebKitWebsiteDataManager may be associated with a WebKitWebContext *or* a WebKitWebView. If the WebKitWebView does not have its own WebKitWebsiteDataManager, then it will use the WebKitWebsiteDataManager of its WebKitWebContext. This means it's now possible for two WebKitWebViews in the same WebKitWebContext to use *different* network processes and NetworkSessions. It also means it's possible for two WebKitWebViews in totally different WebKitWebContexts to use the *same* network process, which was previously not possible. So the APIs really cannot remain part of WebKitWebContext.

I think we can solve this by introducing a new API object, WebKitNetworkSession. It would need to be a property of both the WebKitWebContext and WebKitWebView, exactly the same as WebKitWebsiteDataManager is. The WebKitNetworkSession would have its own website-data-manager property, and would be the object that really owns the WebKitWebsiteDataManager. Then the WebKitWebContext and WebKitWebView website-data-manager properties and getters/setters would instead forward to their WebKitNetworkSession. This means everything would work the same as it does now, but we would effectively have a new API object with a nicer name so that we don't have to confusingly put seemingly-unrelated functions under WebKitWebsiteDataManager.

For now, WebKitNetworkSession would have three functions:

webkit_network_session_get_tls_errors_policy
webkit_network_session_set_tls_errors_policy
webkit_network_session_set_network_proxy_settings

The corresponding WebKitWebContext APIs would remain deprecated, and the corresponding WebKitWebsiteDataManager APIs would be removed (quick! before we release them in 2.32). We could *optionally* deprecate the website-data-manager properties and getters/setters of WebKitWebContext and WebKitWebsiteDataManager, since it might be confusing to have so many different places where you can set a WebKitWebsiteDataManager. But we don't have to do that. This scheme could work either way.

We don't have much time to decide whether to do this. Opinions?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210224/6e94296c/attachment-0001.htm>