<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Please pardon my lack of complete
understanding of this discussion.<br>
<br>
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.<br>
<br>
Will these changes impact this behaviour in anyway?<br>
<br>
Regards,<br>
<br>
Niranjan<br>
<br>
On 06/19/2015 10:42 PM, Carlos Garcia Campos wrote:<br>
</div>
<blockquote cite="mid:1434733932.24133.1.camel@igalia.com"
type="cite">
<pre wrap="">El vie, 19-06-2015 a las 07:11 -0700, Martin Robinson escribió:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
Correct, but we will not expose media keys yet, since we don't support
encrypted media ATM.
</pre>
<blockquote type="cite">
<pre wrap="">My preference here leans toward avoiding setters somehow.
</pre>
</blockquote>
<pre wrap="">
<a class="moz-txt-link-freetext" href="https://bugs.webkit.org/show_bug.cgi?id=146149">https://bugs.webkit.org/show_bug.cgi?id=146149</a>
</pre>
<blockquote type="cite">
<pre wrap="">--Martin
On Fri, Jun 19, 2015 at 2:18 AM, Carlos Garcia Campos
<a class="moz-txt-link-rfc2396E" href="mailto:cgarcia@igalia.com"><cgarcia@igalia.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3">http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3</a>
_______________________________________________
webkit-gtk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a>
<a class="moz-txt-link-freetext" href="https://lists.webkit.org/mailman/listinfo/webkit-gtk">https://lists.webkit.org/mailman/listinfo/webkit-gtk</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
webkit-gtk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:webkit-gtk@lists.webkit.org">webkit-gtk@lists.webkit.org</a>
<a class="moz-txt-link-freetext" href="https://lists.webkit.org/mailman/listinfo/webkit-gtk">https://lists.webkit.org/mailman/listinfo/webkit-gtk</a>
</pre>
</blockquote>
<br>
</body>
</html>