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

[Michael Catanzaro]

On Fri, 2015-06-19 at 11:18 +0200, Carlos Garcia Campos wrote:
> 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);
> .....


Well, thinking about this more....

The problem with this is that the next time we add a new type of
website data -- say, HSTS and HPKP policy stores that necessarily will
reveal your browsing history -- then this will fail unless the app
developer knows to update his app for the new version of WebKit, to
include the new directory in the call to
webkit_website_data_manager_new(). I don't think developers really need
to configure individually directories for websql, indexeddb,
localstorage, etc. More important is to be able to put all those
directories in the same place. So it would suffice to have a pair of
properties to set the cache directory and the data directory, under
which all the individual folders can live, so they don't have to be
listed individually. Then when new types of data are added, they will
automatically go in the right place without us needing to update
applications.

For example, in a tree like this:

~/.local/share/mycoolapp
~/.local/share/mycoolapp/localstorage
~/.local/share/mycoolapp/databases
~/.local/share/mycoolapp/databases/indexeddb
~/.cache/mycoolapp
~/.cache/mycoolapp/offline

mycoolapp should only need to set the two top-level directories
~/.local/share/mycoolapp and ~/.cache/mycoolapp. I think it's harmless
but unessential to allow finer-grained control.