[webkit-gtk] WebsiteDataStore API proposal for process configuration options
mrobinson at webkit.org
Fri Jun 19 07:11:53 PDT 2015
Can you confirm the list of directories that WebsiteDataStore exposes now:
- application cache
- network cache
- indexed database
- local storage
- media keys storage
- web sql storage
My preference here leans toward avoiding setters somehow.
On Fri, Jun 19, 2015 at 2:18 AM, Carlos Garcia Campos
<cgarcia at igalia.com> wrote:
> 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
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
More information about the webkit-gtk