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 <[email protected]> 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk > _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
