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

Carlos Garcia Campos cgarcia at igalia.com
Sat Jun 20 01:03:38 PDT 2015 

El sáb, 20-06-2015 a las 09:47 +0530, Niranjan Rao escribió:
> Please pardon my lack of complete understanding of this discussion.
> 
> We do run multiple instances of web view in multiple processes. Before
> process starts, we set the HOME directory to different location to
> avoid data mixing (cookies/local storage) between two processes. This
> allows us to login to same site with multiple credentials. This works
> correctly.
> 
> Will these changes impact this behaviour in anyway?

No, the default behaviour hasn't changed, if you don't create
WebKitWebsiteDataManager, the web context creates one with the same
default values we currently use. However, you could change to use the
WebKitWebsiteDataManager to set different locations for every context,
and you don't need to change the HOME at all.

> Regards,
> 
> Niranjan
> 
> On 06/19/2015 10:42 PM, Carlos Garcia Campos wrote:
> 
> > 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
> > > > 
> > 
> > 
> > _______________________________________________
> > webkit-gtk mailing list
> > webkit-gtk at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-gtk
> 
> _______________________________________________
> 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/20150620/85fdba3d/attachment.sig>

More information about the webkit-gtk mailing list