Bug 15692 – Gtk Api to check database support and change the path

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Christian Dywan]

The new database storage feature stores databases hidden in the folder $XDG_DATA_HOME/webkit/databases. There is no api to test wether the feature is available at all or to to change the path respectively.

[Christian Dywan]

Created attachment 16863 [details]
A proposal of a possible api

This patch implements webkit_has_database and webkit_set_database_path. This concept is a bit unusual for Gtk+ and not necessarily what we want. Discussion about this is very welcome, especially if you have concrete plans to use this feature.

[Jan Alonzo]

*** Bug 15612 has been marked as a duplicate of this bug. ***

[Kalle Vahlman]

The settings API in WebKit-GTK+ seems to be unsuitable for this, since the path is (as far as I can tell from the code) expected to be a global. There isn't a global version of the settings API (that I know of) but looks like this is at least one instance where we would need one.

One improvement over the current one might be to use g_get_prgname() instead of hard-coded "webkit" in order to not clash between eg. a browser and some other application using WebKit. It's already used in the UA string generation for example, which btw is another candidate for global setting (though maybe that would have use-cases for per-view configuration). Third one I can think of is some cache settings.

I'll refresh the patch to be applyable and move it to webkitprivate.h (there seems to be some other API which is under discussion too), but just to allow people to easily import it if they need the functionality, not for inclusion.

[Christian Dywan]

(In reply to comment #3)
> One improvement over the current one might be to use g_get_prgname() instead of
> hard-coded "webkit" in order to not clash between eg. a browser and some other
> application using WebKit. It's already used in the UA string generation for
> example, which btw is another candidate for global setting (though maybe that
> would have use-cases for per-view configuration). Third one I can think of is
> some cache settings.

I have to disagree with using g_get_prgname(). Usually we want to share things like this. While it should be an optional feature to use for instance databases only in the context of one application, it's not normally very helpful.

[Kalle Vahlman]

(In reply to comment #4)
> (In reply to comment #3)
> > One improvement over the current one might be to use g_get_prgname() instead of
> > hard-coded "webkit" in order to not clash between eg. a browser and some other
> > application using WebKit. It's already used in the UA string generation for
> > example, which btw is another candidate for global setting (though maybe that
> > would have use-cases for per-view configuration). Third one I can think of is
> > some cache settings.
> 
> I have to disagree with using g_get_prgname(). Usually we want to share things
> like this. While it should be an optional feature to use for instance databases
> only in the context of one application, it's not normally very helpful.

Hmm, I suppose you are right. I can imagine for example an music store using the storage area in view embedded in a music application and in a browser session.

Then there's also the question of when this is allowed to be changed? At least it'll ASSERT if a database is open at the time, but does it make any sense to change it after application startup?

[Gustavo Noronha (kov)]

Hey,

(In reply to comment #3)
> I'll refresh the patch to be applyable and move it to webkitprivate.h (there
> seems to be some other API which is under discussion too), but just to allow
> people to easily import it if they need the functionality, not for inclusion.
 
Have you been able to do this work yet? Still plan to do it? =)

[Jan Alonzo]

(In reply to comment #6)
> Hey,
> 
> (In reply to comment #3)
> > I'll refresh the patch to be applyable and move it to webkitprivate.h (there
> > seems to be some other API which is under discussion too), but just to allow
> > people to easily import it if they need the functionality, not for inclusion.
> 
> Have you been able to do this work yet? Still plan to do it? =)

Setting database paths are currently supported in WebCore settings so it might be a good idea to make this a setting (which also make this a per-WebView thing in the API). Apps who want a specific location can just set it to the location they want - and we can just default it to what it is now.

I can cook up a patch if nobody's working on this right now..

[Jan Alonzo]

(In reply to comment #7)
> (In reply to comment #6)
> Setting database paths are currently supported in WebCore settings so it might
> be a good idea to make this a setting (which also make this a per-WebView thing
> in the API). Apps who want a specific location can just set it to the location
> they want - and we can just default it to what it is now.

Correction: setting database paths in Settings is only for localStorage. 

[Jan Alonzo]

You should be able to set the database storage path now that bug #27899 has been fixed.