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 > <[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 > > > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
