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

Carlos Garcia Campos cgarcia at igalia.com
Mon Jun 22 06:55:45 PDT 2015


El lun, 22-06-2015 a las 08:46 -0500, Michael Catanzaro escribió:
> 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.

Yes. I thought about that and I think it's a very good point. We could
probably add base-data-directory and base-cache-directory to
WebKitWebsiteDataManager, and use them if present as fallback when a
particular directory is not provided. So it could be:

if (foo_dir)
    return foo_dir;

if (base_dir)
    return build_foo_dir (base_dir);

return default_foo_dir;

That would allow you to override individual options too. Most of the
directories could be shared among applications using webkitgtk, so you
might want to only provide app directories for a few of them (an all of
them only for private instances).

> _______________________________________________
> 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/20150622/ef875681/attachment.sig>


More information about the webkit-gtk mailing list