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