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

[Carlos Garcia Campos]

El vie, 19-06-2015 a las 07:11 -0700, Martin Robinson escribió:
> 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

Correct, but we will not expose media keys yet, since we don't support
encrypted media ATM.

> My preference here leans toward avoiding setters somehow.

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

> --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
> >
> 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- 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/0c306679/attachment-0001.sig>