[webkit-gtk] WebsiteDataStore API proposal for process configuration options

Carlos Garcia Campos cgarcia at igalia.com
Fri Jun 19 02:18:01 PDT 2015

WebsiteDataStore is a WebKit2 internal class to manage data stored by
websites (cookies, caches, databases, etc.). There are some problems
with our current implementation of this. What we currently have is:

 - WebKitWebContext:local-storage-directory: construct only property
added in 2.8
 - WebKitWebContext:indexed-db-directory: construct only property added
in trunk for 2.10
 - webkit_web_context_set_disk_cache_directory().
 - For all other options (app cache, etc.) the default directory is used
and can't be changed by the user.

This has several problems:

 - The way to specify the different directories is not consistent. 
 - Construct only properties require to use g_object_new to create a new
WebContext, it's not a big deal, but it's not obvious either.
 - Setter methods makes you think that those options can be changed, and
we need to document that you can only call them before anything is
loaded to make sure no network process nor web process have been created
 - Not having an option for all possible config values, means that ephy
web apps or private profiles, are leaving some data outside the profile
dir, for example.

So, to fix all these issues the idea is to expose WebsiteDataStore
somehow in our API. It could be a construct only property of
WebKitWebContext, replacing local-storage-directory and
indexed-db-directory. Adding also a new() method to WebKitWebContext
that receives it.

WebKitWebContext *
webkit_web_context_new_with_website_data_manager (WebKitWebContext         *context,
                                                  WebKitWebsiteDataManager *mamager);

When using webkit_web_context_new() a default website data manager is
created with the default options, keeping the compatibility.

With this we can deprecate WebKitWebContext:local-storage-directory,
remove WebKitWebContext:indexed-db-directory and deprecate also
webkit_web_context_set_disk_cache_directory() and all the issues
mentioned previously would be solved.

Now the thing is how to implement WebKitWebsiteDataManager to avoid
having the same issues we had with the web context, so it should allow
to configure all data store options. And here again we have the same
problem with the options:

 - They could be construct-only properties, so it's clear that they
can't be changed, but then we have the problem of how to create the
object. We could just provide a new() method that uses varargs, and
passes the values to g_object_new_valist(), similar to what
webkit_settings_new_with_settings does. We could have new and
new_with_values, but I think it would be better to only have new()
expecting values (even if you can pass null), since users wanting the
default values don't need to create a manager, letting the web context
create it.
 - Or we could have setters, but again, we would need to document that
they won't have any effect if called after a secondary process has been

So, my proposal here would be something like:

WebKitWebsiteDataManager *
webkit_website_data_manager_new (const gchar *first_option_name,

const gchar *
webkit_website_data_manager_get_local_storage_directory (WebKitWebsiteDataManager *manager);

const gchar *
webkit_website_data_manager_get_disk_cache_directory (WebKitWebsiteDataManager *manager);

This is only for configuration options, which is what we currently have
somehow exposed in our API. However, the WebsiteDataStore also allows to
manage the data, getting a list of origins/domains for a given data
store (like the cookies manager but for databases, local storage, disk
cache, memory cache, etc.). And also allows to remove any particular
data for any origin/domain. We could also expose API for that, which
will allow us to have a proper personal data manager in ephy, for
example. But I'll leave that API proposal for a different mail to not
make this one too long.

Opinions? Objections? Suggestions?

Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150619/58c9aa98/attachment.sig>

More information about the webkit-gtk mailing list