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

[Martin Robinson]

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.

--Martin

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
> yet.
>  - 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
> created.
>
> 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
> http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
>
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
>